- 一般的web結構
在前后台分離的情況下，我們對前端一般會以WEB API的形式同過JSON交互來與前端進行交互。一般來講，我們的數據模型會在controller層進行交互，進行數據的校驗與處理，然后交給service層進行相應的邏輯處理。如果service需要與數據庫的支持，則調用dao層來獲取與存儲數據。這樣分層的好處是當我們的數據存儲方式發生了變化，如我們的數據庫從oracle變成了mysql，我們只要改一下dao層的配置，不會影響我們的業務代碼，特別注意的是，如果service層在調用不同的表時，我們最好調用對應表的service層的方法，不應該出現一個service調用多個dao的情況。
2.分層領域模型
在阿里巴巴編碼規約中列舉了下面幾個領域模型規約:
-
DO（Data Object）：與數據庫表結構一一對應，通過DAO層向上傳輸數據源對象。
-
DTO（Data Transfer Object）：數據傳輸對象，Service或Manager向外傳輸的對象。
-
BO（Business Object）：業務對象。由Service層輸出的封裝業務邏輯的對象。
-
AO（Application Object）：應用對象。在Web層與Service層之間抽象的復用對象模型，極為貼近展示層，復用度不高。
-
VO（View Object）：顯示層對象，通常是Web向模板渲染引擎層傳輸的對象。
-
Query：數據查詢對象，各層接收上層的查詢請求。注意超過2個參數的查詢封裝，禁止使用Map類來傳輸。
而對於數據模型也就是我們所謂的bean來講，我們最好在不同的層里面使用不同的對象。因為這樣可以更靈活的操控不同層的數據
但每一個層基本都自己對應的領域模型，這樣就導致了有些人過於追求每一層都是用自己的領域模型，這樣就導致了一個對象可能會出現3次甚至4次轉換在一次請求中，當返回的時候同樣也會出現3-4次轉換，這樣有可能一次完整的請求-返回會出現很多次對象轉換。如果在開發中真的按照這么來，恐怕就別寫其他的了，一天就光寫這個重復無用的邏輯算了吧。
3.filter與spring
filter是javax.servlet 包中的過濾器，它的加載與控制不受Spring容器的影響，一般由web容器如tomcat通過web.xml來進行加載，所以在使用filter時，我們無法通過spring注解的方式來獲取spring創建的對象。
但如果碰到如filter來判斷用戶是否登陸，我們必須使用spring所創建的緩存對象，怎么辦。這是我們只需要spring中的DelegatingFilterProxy類來對你的filter進行代理，而
DelegatingFilterProxy可以在spring中進行注冊，然后DelegatingFilterProxy再將你的filter注冊進入spring中，這是你就可以使用@Resource,或者@Autowire來獲取你想要的對象了。