一、認識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返回給客戶端。