的確在這些人眼中分層只是乙個形式，前輩們的**這麼寫的，其他專案**這麼寫的，那麼我也這麼跟著寫。但是在真正的團隊開發中每個人的習慣都不同，寫出來的**必然帶著自己的標籤。
有的人習慣controller寫大量的業務邏輯，有的人習慣在service中之間呼叫遠端服務，這樣就導致了每個人的開發**風格完全不同，所以乙個好的應用分層需要具備以下幾點:方便後續**進行維護擴充套件；分層的效果需要讓整個團隊都接受；各個層職責邊界清晰。
每乙個層基本都自己對應的領域模型，這樣就導致了有些人過於追求每一層都是用自己的領域模型，這樣就導致了乙個物件可能會出現3次甚至4次轉換在一次請求中，當返回的時候同樣也會出現3-4次轉換，這樣有可能一次完整的請求-返回會出現很多次物件轉換。如果在開發中真的按照這麼來，恐怕就別寫其他的了，一天就光寫這個重複無用的邏輯算了吧。
所以我們得採取乙個折中的方案:
1、允許service/manager可以運算元據領域模型，對於這個層級來說，本來自己做的工作也是做的是業務邏輯處理和資料組裝。
2、controller/tservice層的領域模型不允許傳入dao層，這樣就不符合職責劃分了。
3、同理，不允許dao層的資料傳入到controller/tservice。
總的來說業務分層對於**規範是比較重要，決定著以後的**是否可復用，是否職責清晰，邊界清晰。當然這種分層其實見仁見智, 團隊中的所有人的分層習慣也不同，所以很難權衡出乙個標準的準則，總的來說只要滿足職責邏輯清晰，後續維護容易，就是好的分層。
你真正的了解MVC三層架構開發模式嗎
的確在這些人眼中分層只是乙個形式，前輩們的 這麼寫的，其他專案 這麼寫的，那麼我也這麼跟著寫。但是在真正的團隊開發中每個人的習慣都不同，寫出來的 必然帶著自己的標籤。有的人習慣controller寫大量的業務邏輯，有的人習慣在service中之間呼叫遠端服務，這樣就導致了每個人的開發 風格完全不同，...
三層呼叫關係 梳理MVC與三層架構的關係
mvc與三層架構 系統架構 系統架構是指，整合應用系統程式大的結構。經常提到的系統結構有兩種 這兩種結構既有區別，又有聯絡。但這兩種結構的使用，均是為了降低系統模 塊間的耦合度。三層架構是指 檢視層 view 服務層 service，與持久層 dao。它們分別完成不同的功能。為了更好的降低各層間的耦...
MVC中Model三層的概念
首先解釋三層的概念，action主要負責表示層，biz負責業務邏輯層，dao負責資料訪問層 表示層 主要是接收使用者輸入資料 表單合法性驗證 和 向使用者展示資料結果 頁面跳轉等 的 業務邏輯層 主要是做業務邏輯的，比如資料的計算等 資料訪問層 主要是負責從資料庫讀取資料並以特定的形式返回的 剛開始...