模型層設計
模型層可以說是運行時系統的工作核心，基本上所有的業務邏輯處理和數據操作都在該層實現。在信息系統中，該層一般會被分成業務服務層（service）和數據訪問層(DAO)。服務層職責是對模塊的“原子用例”進行實現，持久層用於配合服務層的數據存儲操作。在這兩個細分的層次中的所處理的javabean名稱也不一樣，在service中，處理的是bussiness object(bo)，在DAO中，處理的javabean稱爲persistent object(po)。雖然他們代表的意義和職能不一樣，但表現形式卻有可能相同。基於職責的考慮，除非難以本地實現的需求，一般不推薦把業務邏輯放到數據庫的存儲過程中，因爲數據庫上操作是由DBA維護的，web系統無法把控制權延伸到數據庫上。而且這樣破壞了系統的完整性，同時也不利於移植和維護。
Service層設計
首先來分析業務服務層的構造：
服務層與控制層的設計結構基本相同，也是通過一個導航配置查找服務接口，並通過接口獲取所需要的業務數據。在控制層與模型層的通信中，特別加入了適配器，功能類似過濾器，但這裏不是用於安全性的過濾，在之前我們討論分層時都沒涉及到安全性方面的設計，主要考慮安全性每個層次都可能出現，應該作爲一個完整框架單獨進行設計，在web的3層中，它是以“插件”的形式存在。這裏的適配器主要用途在於對用戶請求進行“分級”。所謂“分級”是根據不同角色或權限對請求進行相應的限制。一個例子：不同的銷售人員進行的產品查詢就需要限制查詢出的產品屬於該銷售人員所銷售。通過適配器時，適配器會根據服務配置中的配置從服務層共享數據中獲取所需要的額外信息，並附加到請求數據中，然後再經過服務配置查找相應的服務接口。在分佈式系統中，單點登陸時會設立一個用戶註冊中心用於保存用戶的基本信息，服務層的共享數據與註冊中心的數據同步。如果不使用緩存，使用接口調用代替也是可以的。
接口是不需要“分級”的，接口上的功能點（方法）應該是細粒度的。以上面的查詢爲例，銷售人員查詢對應的功能點所需要的參數必定有個userid來限制輸出的結果集。而不同的角色或等級的查詢也需要不同的調用接口，如主管和銷售人員有不同的查詢接口以讓主管可以獲得到更大範圍的結果集。實現類對接口的實現可以採用如控制層的方式使用“依賴注入”，這樣就需要爲其單獨設計一個配置文件和一個管理類。如果考慮核心業務的性能問題，或者不需要統一管理業務實現，也可以只採用Service service = new ServiceImpl()式的代碼聲明。
Service層的設計原則不需要過多的配置，甚至不用任何的配置也能達到業務邏輯與數據持久層的解藕。由於業務層是改動最爲頻繁的部分，我們需要儘量設計出可以“良性循環”的接口，因爲輸入輸出的格式約定的變更會引起與之聯繫的上下層的改動，而且這種改動有可能引起“聯動效應”導致一些難以預料的隱患，如果能使用同一個javabean作爲輸入輸出參數可以有效的避免這種現象，雖然它確實增加了數據傳輸的成本。 但相對於後期的更新維護所帶來的效益來說，這點是微不足道的。
DAO層設計
Dao層並不是數據持久層，它是操作持久數據的一個訪問對象。所謂的數據持久層應該由數據庫或文件或內存等物理存儲設備充當。Dao的責任在於提供給service訪問數據的能力並負責管理數據操作的監測與性能優化。Dao同樣需要提供接口，供service調用，實現需要在另一個模塊中進行。
數據訪問操作可以說是整個web系統中響應速度最爲緩慢的一環，也是制約web性能的一個瓶頸。因此需要根據訪問對象的特點與訪問的頻度進行優化，緩存和預編譯這兩種技術在這裏體現得淋漓盡致。無論是文件操作還是數據庫訪問，緩存的重要性不言而喻，如果系統使用自身特有的數據訪問語法，就需要使用預編譯技術，預編譯需要進行復雜的詞法、語法、語義分析，然後進行匹配、拆解、合併、優化的反覆循環，最終達到比較高效的數據訪問。預編譯後的內容也同樣需要使用緩存，以降低編譯所帶來的性能損耗。使用系統自身的語法進行數據訪問，可以避免來自上層蹩腳的請求語義直接訪問持久數據帶來的低下性能，而且可以統一開發人員對不同類型的持久數據的訪問方式，減少開發人員編碼量和維護成本。但其缺點也是顯而易見的，編譯器開發難度大，特別是想兼容多種類型的數據訪問時，性能是否得到改善還得看開發編譯器人員的水平。同時新的數據訪問語法也導致了學習成本大大增加。
對於緩存的策略，也是仁者見仁，智者見智。但一般都會參考操作系統原理中的頁面調度算法。比如FIFO（先進先出）、LRU（近期最少使用）、LFU（最近最不常用也稱最佳淘汰）等等。
最後，我們來討論一下實現三層模式框架的優缺點：
優點：不言而喻，良好的解藕設計理念爲模塊化開發奠定了堅實的基礎。在解藕的系統上使用或開發可複用構件是一件很愜意的事情。層與層之間職責分明，分工明確，使得無論是頁面設計人員還是程序開發人員或是數據庫設計人員找到了各自發揮的空間，他們可以相互對立開發互不干擾，他們可以通過設計文檔的接口描述很快找到上下文銜接的方法避免不必要的衝突，這不僅減少了開發中的交流成本，提高了大規模系統的開發效率，也爲系統分析人員和項目經理騰出之前在職責協調中的浪費的大量時間而專於業務需求的管理和技術的改進。
缺點：在任何一個基礎平臺，無論是J2EE還是.NET，它們的長處都在於數據的處理而不在於數據的展現，web的表現技術和桌面應用程序的表現技術相比，無論是表現手段、人性化還是響應速度都有所欠缺。實現一個相對複雜的表現方式，開發人員需要付出大量的精力，開發的效率會因此大打折扣。這一點，在開發小型系統上尤其明顯。基於三層的web系統在層間通信時會帶來性能損耗，複雜的配置降低了系統的負載能力，不適合將其作爲門戶網站等對併發要求很高的系統。
Web分層設計與研究的三層模型設計到現在基本完成，在這裏我們詳細的討論了各個層次的結構和責任，設想了這三層的實現方式。但真正要以三層模式爲核心蓋起完整的框架還有很多工作要做，一個可以在實際生產中發揮威力的系統框架往往是經過千錘百煉才形成的。儘管如此，我們仍然有必要爲了去驗證我們的設想而接受這種挑戰，要提高自身的領域建模能力，這一步是必不可少的。