【MarketAnalysis總結】1.0分層體系架構
MarketAnalysis專案十二月份已經全部完工了,之後一直忙於期末考試和其他課設,一直沒把總結放上來;為了筆記不遺失也方便以後查詢還是放上來吧。
這次專案,我花了比較多的心血在這上面,完整地跟進了整個專案,從開題之後每個階段都緊跟著團隊的腳步,也推動著團隊往前走。在這個過程中,我收穫了很多專案經驗,不止是從技術層面,對於現有的web的技術從底層到最新都有個大概的瞭解了,更從團隊合作中的獲取了團隊經驗,包括專案管理的git使用以及體會到了分層體系架構給我帶來的好處,還有日常與隊友如何對接,溝通交流的經驗,可以說是真的受益匪淺。
我在本次專案中負責的後端的工作有搭建Spring框架、搭建SpringMVC框架、從Strut2+Spring+Hibernate到SpringMVC+Spring+Hibernate的整合、對專案進行層次體系結構設計分層、使用者許可權控制、使用者賬戶安全訪問控制以及傳送手機驗證碼模組。
我會把每一部分的工作都一一總結,這裡先介紹對專案進行分層體系結構設計。
該專案通過SSH框架搭建,專案結構如下圖1.1所示。
圖1.1 專案框架圖
後端之所以這樣分層,原因在於把專案解耦,把模型、檢視、控制分開,獨立工作,方便團隊合作編碼與整合。其各層詳細的作用描述如下:
1) Controller(控制層)
控制層是整個專案的指揮中樞,主要控制頁面間的跳轉,接收前端的請求並分發請求,以及前後臺數據的傳輸。前端所有的請求,都要彙集先到該層,再由控制層統一把需求分發到對應的業務邏輯層獲取相應的服務,處理完畢後再經過控制層回覆給前端。
前端請求到後端處理並返回的實現流程如下:
a) 前端通過url向後端發來請求以及資料,後端一直處在待接收請求的狀態;
b) 通過匹配url分發到後端controller的一個函式,對該請求進行處理;
c) 所匹配的函式呼叫Service層對應的服務並處理加工資料後,Service層向controller返回一個結果,再由controller應答前端。
- Interceptor(攔截層)
攔截層是在Controller層之前的一層,它可以在某些特定的請求(可以自己設計)到達控制層之前攔截下來,對其進行許可權校驗、身份校驗、合法性檢查、避免過量請求湧入等操作。
在本次專案中,攔截層主要做了對下載許可權、查詢許可權的校驗、是否在登入狀態訪問的控制、以及檢查前端請求是否合法的工作。每一個功能分別如下圖1.2對應的DownloadInterceptor、QueryInterceptor、LoginInterceptor和AfterLoginInterceptor、IndexInterceptor五個類。
圖1.2 攔截層
2) Service(業務邏輯層)
業務邏輯層也稱服務層,是控制層的下一層,負責接收來自控制層分發的需求,為其提供相應的服務的,例如資料加工處理。
Service層負責的工作流程如下:
a) 控制層呼叫service層相應的服務,並傳入要處理的原始資料;
b) Service層接收到原始資料,開始對資料進行加工,呼叫DAO層提供的介面,對資料庫進行操作;
c) 處理完畢後返回加工後的資料給controller。
3) DAO(資料庫訪問層)
資料庫訪問層顧名思義是負責對資料庫訪問的操作的,是Service層的下一層。它不包含業務邏輯,主要封裝了對資料庫的連線、關閉、增刪查改等操作,以便給它的上一層Service提供相應的資料庫服務,是較底層的一層。
4) Cache(快取層)
快取層主要負責對已查詢過的資料進行快取,並定時重新整理。該層的作用是解決對大量資料的查詢有很大的時間開銷問題。
5) Entity(實體層)
實體層是最底層的一層,直接對應資料庫的表。該層封裝著每張表的Javabean(對應著一個個類),以及對應的對映配置檔案。它負責把資料庫裡的表對映到Javabean,以便DAO對資料庫操作。
至此,我詳細地介紹了每一層的作用,以及為什麼這樣分層。由於前端的各層作用不是我負責的範圍,故在此不做過多贅述。