MVC設計模式

MVC模式（Model-View-Controller）是軟件工程中的一種軟件架構模式，把軟件系統分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）
它是用一種業務邏輯、數據與界面顯示分離的方法來組織代碼，將眾多的業務邏輯聚集到一個部件里面，在需要改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯，達到減少編碼的時間，提高代碼復用性。

控制器（Controller）：Servlet，控制器主要處理用戶的請求。
指從現實世界中抽象出來的對象模型，是應用邏輯的反應；它封裝了數據和對數據的操作，是實際進行數據處理的地方（模型層與數據庫才有交互）

視圖（View）：HTML, JSP, 前端框架。是應用和用戶之間的接口，它負責將應用顯示給用戶 和 顯示模型的狀態。

模型（Model）：邏輯業務程序（后臺的功能程序）, Service, Dao, JavaBean。
控制器負責視圖和模型之間的交互，控制對用戶輸入的響應、響應方式和流程；它主要負責兩方面的動作，一是把用戶的請求分發到相應的模型，二是吧模型的改變及時地反映到視圖上。

V即View視圖是指用戶看到并與之交互的界面。比如由html元素組成的網頁界面，或者軟件的客戶端界面。MVC的好處之一在于它能為應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發生，它只是作為一種輸出數據并允許用戶操縱的方式。

C即controller控制器是指控制器接受用戶的輸入并調用模型和視圖去完成用戶的需求，控制器本身不輸出任何東西和做任何處理。它只是接收請求并決定調用哪個模型構件去處理請求，然后再確定用哪個視圖來顯示返回的數據。

用戶首先在界面中進行人機交互，然后請求發送到控制器，控制器根據請求類型和請求的指令發送到相應的模型，模型可以與數據庫進行交互，進行增刪改查操作，完成之后，根據業務的邏輯選擇相應的視圖進行顯示，此時用戶獲得此次交互的反饋信息，用戶可以進行下一步交互，如此循環。

需要注意的是：MVC三層結構與軟件的三層結構是有區別的。MVC是一種設計模式，三層結構是軟件結構，用MVC這種設計模式可以實現三層軟件結構。在完整三層軟件結構中 表現層包括了MVC中的表現層和控制層。而MVC中的模型層其實包括了三層軟件結構的業務邏輯層、數據訪問層、業務實體類（model）和共用類。軟件三層結構的UI（Web）包含了MVC中的視圖層（V）和控制層（C）。

MVC的目的

它將這些對象、顯示、控制分離以提高軟件的的靈活性和復用性，MVC結構可以使程序具有對象化的特征，也更容易維護。

MVC舉例

jsp+servlet+javabean模式

JavaBean作為模型，既可以作為數據模型來封裝業務數據，又可以作為業務邏輯模型來包含應用的業務操作。其中，數據模型用來存儲或傳遞業務數據，而業務邏輯模型接收到控制器傳過來的模型更新請求后，執行特定的業務邏輯處理，然后返回相應的執行結果。

JSP作為視圖層，負責提供頁面為用戶展示數據，提供相應的表單（Form）來用于用戶的請求，并在適當的時候（點擊按鈕）向控制器發出請求來請求模型進行更新。

Serlvet作為控制器，用來接收用戶提交的請求，然后獲取請求中的數據，將之轉換為業務模型需要的數據模型，然后調用業務模型相應的業務方法進行更新，同時根據業務執行結果來選擇要返回的視圖。

MVC設計模式相對于模式1（虛線表示模式1，不是MVC，即JSP+JavaBean），把模式1 的表現層中的頁面與表現邏輯（流程控制）分開。
視圖層只負責頁面的顯示，而數據的獲取、調用業務邏輯和頁面的選擇均由控制層完成。
在MVC模式中，視圖層用JSP、HTML、CSS和JavaScript技術來實現；

MVC的優點

1.耦合性低

視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。

2.重用性高

MVC模式允許使用各種不同樣式的視圖來訪問同一個服務器端的代碼，因為多個視圖能共享一個模型，它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由于模型返回的數據沒有進行格式化，所以同樣的構件能被不同的界面使用。

3.部署快，生命周期成本低

MVC使開發和維護用戶接口的技術含量降低。使用MVC模式使開發時間得到相當大的縮減，它使程序員（Java開發人員）集中精力于業務邏輯，界面程序員（HTML和JSP開發人員）集中精力于表現形式上。

4.可維護性高

分離視圖層和業務邏輯層也使得WEB應用更易于維護和修改。

MVC的缺點

1.完全理解MVC比較復雜

由于MVC模式提出的時間不長，加上同學們的實踐經驗不足，所以完全理解并掌握MVC不是一個很容易的過程。

2.調試困難

因為模型和視圖要嚴格的分離，這樣也給調試應用程序帶來了一定的困難，每個構件在使用之前都需要經過徹底的測試。

3.不適合小型，中等規模的應用程序

在一個中小型的應用程序中，強制性的使用MVC進行開發，往往會花費大量時間，并且不能體現MVC的優勢，同時會使開發變得繁瑣。

4.增加系統結構和實現的復雜性

對于簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的復雜性，并可能產生過多的更新操作，降低運行效率。

5.視圖與控制器間的過于緊密的連接并且降低了視圖對模型數據的訪問

視圖與控制器是相互分離，但卻是聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。

依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。

Modle 發展史

JSP Model1第一代
所有的業務邏輯交個jsp單獨處理完成，一個web項目只存在DB層和JSP層，所有的東西都耦合在一起，對后期的維護和擴展極為不利。

JSP Model1第二代

JSP Model1第二代有所改進，把業務邏輯的內容放到了JavaBean中，而JSP頁面負責顯示以及請求調度的工作。雖然第二代比第一代好了些，但JSP還是把view和control的業務耦合在一起。

JSP Model2
JSP Model2 就是現在大力推廣的和使用的mvc，將一個項目劃分為三個模塊，各司其事互不干擾，既解決了jsp所形成的耦合性，又增加了邏輯性、業務性以及復用性和維護性。

項目分層

DAO —— Data Access Object數據訪問對象（接口）
DAOImpl —— DAO的實現類
entity ——數據對象的實體（有些地方叫model層）
Service（不是Server）——就是中間層、業務邏輯層（接口）
ServiceImpl —Service的實現類
Util —— 自定義工具類 Servlet——JAVA WEB小應用（有時叫Controller層）

1、Utils：主要用于存放連接工具如java數據庫連接工具,在這里提供連接和關閉數據庫的接口。
2、Dao層: 上面Util包中已經提供連接數據庫接口，在本層中可直接調用，然后創建增刪改查語句。
3、Service層：最重要的一層，對servlet層傳入的數據，調用Dao層的方法操作和整合。
4、Servlet層：對Jsp中傳入的數據，封裝調用service操作。
5、test層：用單元測試的方式，沒有問題再進行接下來的操作。
6、Bean層里是建立的模型層
一般情況下，Dao層、service層還要分為兩層，一層是接口，另外一層做實現類。

1.JAVA中Servlet層、Service層 、modle層 、 Dao層的功能區分？

Servlet層用于接收請求并且調用對應service層處理請求，是Java各層中最接近瀏覽器的一層。Service層主要編寫具體業務邏輯，每個Service一般包含一組相關的業務邏輯

modle/entity層（統稱模型層）對應的數據庫表的實體類，一般每個模型層類對應一個數據庫“表”，一般是用于ORM對象關系映射，一方面方便從數據庫取數據時保存為類，一方面也方便寫入數據庫，簡而言之就是為了方便操作數據庫

Dao層一般用于對數據庫的具體操作，包括各種具體的增刪改查語句和數據庫數據和Java模型的映射。Util層主要用于存在項目各層都有可能出現、不好劃分到某層中、出現頻率較高的功能（類），比如連接數據庫、獲取系統參數、導出Excel表等等

2.為什么將Service（Dao）層設為接口層，單獨拿出一個ServiceImpl（DaoImpl）作為實現層？

方便項目管理，增加代碼的復用性。
當項目很大、代碼很多時，可能存在多種業務邏輯類似但具體業務有所區別的需求，此時讓它們都集成同一個接口層方便處理。

3.為什么要用service層封裝？

一般某一個程序的有些業務流程需要連接數據庫，有些不需要與數據庫打交道而直接是一些業務處理，這樣就需要我們整合起來到service中去，這樣可以起到一個更好的開發與維護的作用，同時也是MVC設計模式中model層功能的體現

4 . Entity、Pojo、JavaBean和DTO有什么區別？

Entity：實體bean，一般是用于ORM對象關系映射，一個實體映射成一張表，一般無業務邏輯代碼，有些優秀框架中修改entity會直接同步到數據庫。

JavaBean：是一種Java語言寫成的可重用組件，類必須是具體和公共的，并且具有無參數的構造器，可以把數據封裝起來，把應用的業務邏輯和顯示邏輯分離開，降低了開發的復雜程度和維護成本（說白了就是一種類的規范，符合這種規范的都可以叫JavaBean）

Pojo：簡單的Java對象，實際就是普通JavaBeans，是為了避免和EJB混淆所創造的簡稱。

DTO：數據傳輸對象（Data TransferObject），是一種設計模式之間傳輸數據的軟件應用系統。

5.模型類和VO、DTO、DO、PO分別是什么

VO（View Object）：視圖對象，用于展示層，它的作用是把某個指定頁面（或組件）的所有數據封裝起來。

DTO（Data Transfer Object）：數據傳輸對象，這個概念來源于J2EE的設計模式，原來的目的是為了EJB的分布式應用提供粗粒度的數據實體，以減少分布式調用的次數，從而提高分布式調用的性能和降低網絡負載，但在這里，我泛指用于展示層與服務層之間的數據傳輸對象。

DO（Domain Object）：領域對象，就是從現實世界中抽象出來的有形或無形的業務實體。
PO（PersistentObject）：持久化對象，它跟持久層（通常是關系型數據庫）的數據結構形成一一對應的映射關系，如果持久層是關系型數據庫，那么，數據表中的每個字段（或若干個）就對應PO的一個（或若干個）屬性。

模型層：
下面以一個時序圖建立簡單模型來描述上述對象在三層架構應用中的位置

用戶發出請求（可能是填寫表單），表單的數據在展示層被匹配為VO。
展示層把VO轉換為服務層對應方法所要求的DTO，傳送給服務層。 l
服務層首先根據DTO的數據構造（或重建）一個DO，調用DO的業務方法完成具體業務。
服務層把DO轉換為持久層對應的PO（可以使用ORM工具，也可以不用），調用持久層的持久化方法，把PO傳遞給它，完成持久化操作。
對于一個逆向操作，如讀取數據，也是用類似的方式轉換和傳遞。

三層架構

三層由表現層(UI)、業務邏輯層(BLL)、數據訪問層(DAL)組成。

1.表現層（web層）：包含JSP，Servlet等web相關的內容
??職責：①向用戶展示特定的業務數據
?????②采集用戶的信息和操作
??原則：用戶至上，兼顧簡潔

2.業務邏輯層（Service層）： 處理業務，不允許出現servlet中的request、response。
??職責：① 從UI中獲取用戶指令和數據，執行業務邏輯
?????②從UI中獲取用戶指令和數據，通過DAL寫入數據源
?????③從DAL中獲取數據，以供 UI 顯示用
??機制：① UI –> BLL –> UI
?????② UI –> BLL –> DAL –> BLL –> UI

3.數據訪問層（持久層）：封裝了對數據庫的訪問細節。
??作用：跟數據源打交道
??職責：①執行對數據的操作（增刪改查）
注意：其中 web層相當于mvc中的view，Service層和dao層相當于mvc中的modle。

4.數據對象層
??數據對象層包含了項目需要使用的數據對象，用數據對象來傳遞數據，它避免了各個層的交叉引用。
??一般一個表對應一個數據對象。

UI():主要是指與用戶交互的界面。用于接收用戶輸入的數據和顯示處理后用戶需要的數據。

BLL:(業務邏輯層):UI層和DAL層之間的橋梁。實現業務邏輯。業務邏輯具體包含：驗證、計算、業務規則等等。

DAL:(數據訪問層):與數據庫打交道。主要實現對數據的增、刪、改、查。將存儲在數據庫中的數據提交給業務層，同時將業務層處理的數據保存到數據庫。（當然這些操作都是基于UI層的。用戶的需求反映給界面（UI），UI反映給BLL，BLL反映給DAL，DAL進行數據的操作，操作后再一 一 返回，直到將用戶所需數據反饋給用戶）