spring---web項目結構分層

1. 通常的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來獲取你想要的對象了。