JavaWeb開發中的分層思想（一）

JavaWeb開發分層思想（一）

一、認識DAO、Service、Controller層

DAO（Data Access Object）

1、直接看英文意思就是“資料通路對象”，也就是做一個“接口”

而DAO層主要是做資料持久層的工作，負責與資料庫進行聯絡的一些任務都封裝在此，DAO層的設計首先是設計DAO的接口，然後在Spring的配置檔案中定義此接口的實作類，然後就可在子產品中調用此接口來進行資料業務的處理，而不用關心此接口的具體實作類是哪個類，顯得結構非常清晰，DAO層的資料源配置，以及有關資料庫連接配接的參數都在Spring的配置檔案中進行配置

2、簡單來說就是Dao層一般用于對資料庫的具體操作，包括各種具體的增删改查語句和資料庫資料和Java模型的映射。

Service（中間層、業務邏輯層—做個接口）

1、Service層主要編寫具體業務邏輯，每個Service一般包含一組相關的業務邏輯（比如“使用者管理”是一個Service，”文章管理“是一個Service）

Service層主要負責業務子產品的邏輯應用設計。同樣是首先設計接口，再設計其實作的類，接着在Spring的配置檔案中配置其實作的關聯。這樣我們就可以在應用中調用Service接口來進行業務處理。Service層的業務實作，具體要調用到已定義的DAO層的接口，封裝Service層的業務邏輯有利于通用的業務邏輯的獨立性和重複利用性，程式顯得非常簡潔。

Controaller（控制層）

1、其實相當于Servlet那一層所做的事

Controller層負責具體的業務子產品流程的控制，在此層裡面要調用Serice層的接口來控制業務流程，控制的配置也同樣是在Spring的配置檔案裡面進行，針對具體的業務流程，會有不同的控制器，我們具體的設計過程中可以将流程進行抽象歸納，設計出可以重複利用的子單元流程子產品，這樣不僅使程式結構變得清晰，也大大減少了代碼量。

二、編寫代碼

1、開發代碼應該從底層做起，避免代碼的繁雜修改以及需求變化。

Service層是建立在DAO層之上的，建立了DAO層後才可以建立Service層，而Service層又是在Controller層之下的，因而Service層應該既調用DAO層的接口，又要提供接口給Controller層的類來進行調用，它剛好處于一個中間層的位置。每個模型都有一個Service接口，每個接口分别封裝各自的業務處理方法

2、從圖中可以看出，我們應該從底層的DAO層到service層到servlet層這個順序做也就是從底層做起。

三、關于這些開發層所遇到一些問題

1、 為什麼将Service（Dao）層設為接口層，單獨拿出一個ServiceImpl（DaoImpl）作為實作層

主要還是為了友善項目管理，增加代碼的複用性。當項目很大、代碼很多時，可能存在多種業務邏輯類似但具體業務有所差別的需求，此時讓它們都內建同一個接口層就好了（隻是情景之一）

2、為什麼要用service層封裝

這個問題就像Java為什麼要分層一樣。一般來說，某一個程式的有些業務流程需要連接配接資料庫，有些不需要與資料庫打交道而直接是一些業務處理，這樣就需要我們整合起來到service中去，這樣可以起到一個更好的開發與維護的作用，同時也是MVC設計模式中model層功能的展現

3、Entity、Pojo、JavaBean和DTO有什麼差別？

Entity：實體bean，一般是用于ORM對象關系映射，一個實體映射成一張表，一般無業務邏輯代碼，有些優秀架構中修改entity會直接同步到資料庫。JavaBean：是一種Java語言寫成的可重用元件，類必須是具體和公共的，并且具有無參數的構造器，可以把資料封裝起來，把應用的業務邏輯和顯示邏輯分離開，降低了開發的複雜程度和維護成本（說白了就是一種類的規範，符合這種規範的都可以叫JavaBean）。Pojo：簡單的Java對象，實際就是普通JavaBeans，是為了避免和EJB混淆所創造的簡稱。DTO：資料傳輸對象（Data Transfer Object），是一種設計模式之間傳輸資料的軟體應用系統。（其實一般開發很難也不必去感受它們的差别，開發多了感覺就來了）

4、模型類和VO類分别是什麼

模型類一般都會與資料庫一一對應（見上文），但僅有模型類無法滿足所有需求場景（多表查詢）：對于一個商城網站，商品詳情頁面不僅要顯示商品的一般資訊，還要顯示所屬店家資訊、店主資訊、地理位置……此時資料庫商品表中不可能存這麼多字段（這會造成很大備援），解決方案之一就是開發者手動分别查詢商品表、店鋪表、店主表資料然後将需要的資料拼接在一起傳到前端，但這種方法會讓開發者浪費不少時間。與此相對的另一個更好的方案是，我們可以将商品詳情頁需要的資料單獨再封裝成一個實體類——這便是VO類，我們在想要擷取商品詳情時單獨寫一個查詢方法對應VO（可以直接将查詢結果封裝到VO中）便可實作想要的效果。簡而言之，模型類對應資料庫中“表”，VO類對應前端具體視圖（或者說VO類對應資料庫中“視圖”）

以上四個問題收藏來源于該部落格https://blog.csdn.net/cx776474961/article/details/78467829

四、關于servlet是什麼的問題

作者：柳樹

連結：https://www.zhihu.com/question/21416727/answer/339012081

這個提問的最大一個bug，就是以為servlet是很複雜的東西，事實上，servlet就是一個Java接口，interface! 打開idea，ctrl + shift + n，搜尋servlet，就可以看到是一個隻有5個方法的interface!

是以，提問中說的網絡協定、http什麼的，servlet根本不管！也管不着！

那servlet是幹嘛的？很簡單，接口的作用是什麼？規範呗！

servlet接口定義的是一套處理網絡請求的規範，所有實作servlet的類，都需要實作它那五個方法，其中最主要的是兩個生命周期方法 init()和destroy()，還有一個處理請求的service()，也就是說，所有實作servlet接口的類，或者說，所有想要處理網絡請求的類，都需要回答這三個問題：

• 你初始化時要做什麼
• 你銷毀時要做什麼
• 你接受到請求時要做什麼

這是Java給的一種規範！就像阿西莫夫的機器人三大定律、行屍走肉裡Rick的那三個問題一樣，規範！

servlet是一個規範，那實作了servlet的類，就能處理請求了嗎？

答案是，不能。

你可以随便谷歌一個servlet的hello world教程，裡面都會讓你寫一個servlet，相信我，你從來不會在servlet中寫什麼監聽8080端口的代碼，servlet不會直接和用戶端打交道！

那請求怎麼來到servlet呢？答案是servlet容器，比如我們最常用的tomcat，同樣，你可以随便谷歌一個servlet的hello world教程，裡面肯定會讓你把servlet部署到一個容器中，不然你的servlet壓根不會起作用。

tomcat才是與用戶端直接打交道的家夥，他監聽了端口，請求過來後，根據url等資訊，确定要将請求交給哪個servlet去處理，然後調用那個servlet的service方法，service方法傳回一個response對象，tomcat再把這個response傳回給用戶端。