按照分層開發的觀點，可以將應用劃分為：表示層、業務邏輯層和持久層，每一層都有屬於自己類別的設計模式。
表示層設計模式：
interceptor filter：攔截過濾器，提供請求預處理和後處理的方案，可以對請求和響應進行過濾。/p>
front controller：通過**控制器提供請求管理和處理，管理內容讀取、安全性、檢視管理和導航等功能。struts 2中的strutsprepareandexecutefilter、spring mvc中的dispatcherservlet都是前端控制器，後者如下圖所示：
view helper：檢視幫助器，負責將顯示邏輯和業務邏輯分開。顯示的部分放在檢視元件中，業務邏輯**放在幫助器中，典型的功能是內容讀取、驗證與適配。
composite view：復合檢視。
業務邏輯層設計模式：
business delegate：業務委託，減少表示層和業務邏輯層之間的耦合。
value object：值物件，解決層之間交換資料的開銷問題。
session façade：會話門面，隱藏業務邏輯元件的細節，集中工作流程。
value object assembler：靈活的組裝不同的值物件
value list handler：提供執行查詢和處理結果的解決方案，還可以快取查詢結果，從而達到提公升效能的目的。
service locator：服務定位器，可以查詢、建立和定位服務工廠，封裝其實現細節，減少複雜性，提供單個控制點，通過快取提高效能。
持久層設計模式：
data access object：資料訪問物件，以物件導向的方式完成對資料的增刪改查。
企業級API設計
最近對service的api設計，在team內有些討論，主要集中在api是足夠抽象 通用好呢，還是具體 易用好？其實這個是要折衷的，通用的好處是以後更改api的可能性小，但壞處是想要通用，裡面的字段就不能定義太死，不定義死，極端的例子是全部用name value pair，最通用，但client面對...
企業級開發的思考
曾經自己一直覺得企業級開發是神聖的，是不容質疑的。雖然有時候自己也認可 多大屁股穿多大褲衩 的道理，可是那種重量級的開發模式在自己心目中占領的位置一直是不容侵犯的。直到近期公司打算要做個東西的時候才發現企業級真的非常重，重到90 以上的情況用不到。之前考慮過ejb和spring。自己一直覺得僅僅有e...
企業級開發從業感受
做企業級開發也有段時間了，基本上該了解的都了解了。做為乙個行業來說，這個行業的企業家不是很好過啊。不管哪個行業都在一步步的壓縮成本。而且還是發包方一廂情願式的，物價 專案的收入反而降低了。開發人員的收入就沒有以前那麼多了 另外，付款模式上面不管是 的二三三二式付款方式還是銀行的八二式付款方式，20 ...