網路應用程式的架構

     隨著技術的發展，網路開發的分工越來越細了，如何進行更加細緻的分工是當前提高開發的效率的一個重點之一。因此，j2ee很多架構都努力向更加明確的分工發展，這幾年來，MVC架構滿天飛，關於架構的技術也不斷的發展與成熟，諸如：struts，webwork，spring mvc都是其中的代表，同時由於組件技術的發展，如何更好的的把組件引入商業網站開發中也是一大焦點問題。前一種方式是基於使用者的請求和url處理來反饋使用者資訊，後一種是通過組件的點擊並反應的思想來考慮，這兩種處理使用者請求的思想是當前的兩大架構主流。
     讓我們回顧一下網路的發展，
      1）html超文本協議可以為客戶顯示豐富的內容，但是如果就這些單一的網頁內容並沒有什麼意義，這種情況使用者並不能與伺服器進行互動，並根據個人的資訊來處理相應的要求。加上電腦本來就是為使用者進行服務的，從這方面來考慮，每一台提供了某些服務的電腦都算是服務，正如在現實中你去超市，超市為你提供你所需要的產品，超市與網路中的一台伺服器沒有什麼區別。就這個意義來說，我們至少都需要提供別人所需的，明白這一點是最重要的。
     2）明白了一台伺服器就是為了提供服務之後，我們需要繼續瞭解的是如何基於這些服務來開發別人所需要的功能。web services就是這種的一種高層次的技術，面向服務開發，我們現在不需要瞭解其底層的分散式運算等技術，我們首先需要注意的是，通過這種技術，我們可以更加的集中於服務的開發，所以我們現在要知道面向服務開發的技術對我們來說是多麼的重要了。
    3）我們來繼續考慮一下客戶與伺服器之間的互動。既然已明白了伺服器就像超市那樣為你提供了某些服務，那麼自然的想到的開發方式是使用者向伺服器發出請求，伺服器然後應答你的需求，自然而然的發展就是這樣，因此這種是一種應答式的模式。事實上這種方式一直都很正確，但是對於程式員來說一直都沒有成熟，程式員需要的是一種層次分明的模式來進行開發，他們的需求是根據最原始的要求那樣：使用者在瀏覽資訊時，這就需要一個view層，不應該與用戶端的內容聯絡在一起；而當需要提交一些內容給伺服器處理時，這些內容也需要分離，作為一個model層；最為如何處理這些資料，則是伺服器的問題，處理的方式是control層。這三層需要嚴格分離，同時這三層之間都是鬆散的，並各自都可以重用，這樣在開發過程中就可以脈絡清晰，具有更加高的效率。
          但是事實上，技術並沒有向我們想象中的那麼統一，比如在html文本本來作為一個通用的標準，就我認為，作為web層的表示內容基本足夠，當需要動態反饋內容插入的時候，我覺得應該通過一個模板來插入，這也是我推薦模板式的而不是jsp等內容的原因之一，但是事實上很多架構都與web層緊耦合，破壞了可觀性，同時也增加了開發過程的難度，這點在降低耦合性上，tapestry的模板機制用的非常棒；在control層上，這裡應該提供所有的邏輯處理，這些處理也必須可以重用才行，但是技術一直都沒有很好的向這個方向發展，不過，最近的spring-webflow在這方面的努力比較多（裡面的根據狀態來考慮使用者的思想是一個很有趣的問題）。在這層上，有個很理性化的問題，那就是驗證問題，驗證就我認為，很多地方應該是伺服器問題（除了基本的js瀏覽器指令碼驗證），所以應該納入control層上，而且要針對那些模型對象，這也是我比較贊同spring中的驗證的基本思想；在model層就沒有什麼好看頭了，主要通過容器來把這些模型與其他結合就行了，這些類建議一般都應該為pojo類，並應該能serializable，同時都是使用orm工具來進行資料庫訪問。
      4）交易處理的技術，應該提供提交，復原等交易處理功能。在這方面，spring做的不錯，輕型的容器交易管理功能。
      5）IoC與Mock：如何把那三層松耦合的內容整合在一起？這就是容器的功能所在了，IoC的容器提供了極為強大的整合類的功能，降低了耦合行。Mock對象與Cuckoo Pattern的應用也是緊密相關的，這些內容在現代的AOP開發過程中經常可以看到。