原文出處：https://blog.csdn.net/zdwzzu2006/article/details/6086829

view層：    結合control層，顯示前臺頁面。
control層：業務模組流程控制，呼叫service層介面。
service層：業務操作實現類，呼叫dao層介面。
dao層：     資料業務處理，持久化操作
model層： pojo，OR maping，持久層

延伸閱讀：關於view、controller、service、dao的理解

首先，分層的目的：高內聚，低耦合。雖然有時候一個controller方法裡面僅僅呼叫一個service的方法，一個service方法裡面僅僅呼叫一個dao層裡的方法，但是，這幾層還是非常有必要存在的。

一、這樣看起來結構是很清晰的，雖然對很對新人來說確實看起來很複雜；

二、可擴充套件性和適應性更加強，比如將來使用者的業務邏輯有一定的改變，你需要做的僅僅就是在service層中多呼叫一個方法即可，而不需要對程式碼有太多的改動，抑或是你將來想換個mvc的框架的話，只需要對接收和返回引數方面做些處理即可，而不需要對service層和dao層做任何改動；

三、維護更加簡單，其實這個和第二點有點相似，不過，不同的是將來維護的不一定是你本人或者開發這個系統的人，所以，如果你嚴格按照這種架構來寫的話，他們只需要有這種分層意識，很容易就能夠對系統有個很好的掌握，也很容易能夠對問題進行排查和修改。

• view：
  檢視。這個很容易理解，其實view層就是使用者使用者可以看到的東西。後臺怎麼處理不關心，只關心怎麼樣想使用者展示資訊。
• controller：
  也可以成為action層，集合了各種action、業務模組流程。我經常喜歡用控制檢視的跳轉來簡單形容，但是這個是不全面的，因為他除了控制檢視的轉換之外，還控制了業務的邏輯，但是，這裡的控制業務邏輯不是業務邏輯的實現，而僅僅是一個大的模組，你看到之後，知道它實現了這個業務邏輯，但是怎麼實現的，不需要關心，僅僅需要呼叫service層裡的一個方法即可，這樣使controller層看起來更加清晰。
• service：
  業務邏輯層。接著controller層中，可以想到，service層是業務邏輯（商務邏輯）的具體實現
  。它向上層的controller層提供介面，並且使用dao層提供的介面。存在的必要性：有時候，我認為更多的時刻，service層中僅僅是呼叫dao層中的一個方法，那麼它是否有必要存在呢？答案是肯定的。因為，假如將來客戶的業務有一定的變動，那麼這樣一來，你只需要在service層中進行一些變動即可。記住，你寫程式不應該僅僅為實現功能考慮，更多的還是應該為將來的維護考慮，因為大部分的時間還是在維護上的。
• dao：
  資料訪問物件。他只負責對資料進行訪問，而不管其他的什麼業務邏輯，其實就是隻幹活，而不管為什麼幹。在dao層裡面要完成的是資料訪問邏輯以及對資料的訪問。資料訪問，大部分情況下就是對資料進行操作。dao層為上層的service層提供介面。dao層在操作完成後，如果是查詢，則返回物件，如果是增刪改，則僅僅需要返回一個boolean值表示成功失敗即可。