的確在這些人眼中分層只是乙個形式，前輩們的**這麼寫的，其他專案**這麼寫的，那麼我也這麼跟著寫。但是在真正的團隊開發中每個人的習慣都不同，寫出來的**必然帶著自己的標籤。
有的人習慣controller寫大量的業務邏輯，有的人習慣在service中之間呼叫遠端服務，這樣就導致了每個人的開發**風格完全不同，所以乙個好的應用分層需要具備以下幾點:方便後續**進行維護擴充套件；分層的效果需要讓整個團隊都接受；各個層職責邊界清晰。
每乙個層基本都自己對應的領域模型，這樣就導致了有些人過於追求每一層都是用自己的領域模型，這樣就導致了乙個物件可能會出現3次甚至4次轉換在一次請求中，當返回的時候同樣也會出現3-4次轉換，這樣有可能一次完整的請求-返回會出現很多次物件轉換。如果在開發中真的按照這麼來，恐怕就別寫其他的了，一天就光寫這個重複無用的邏輯算了吧。
所以我們得採取乙個折中的方案:
1、允許service/manager可以運算元據領域模型，對於這個層級來說，本來自己做的工作也是做的是業務邏輯處理和資料組裝。
2、controller/tservice層的領域模型不允許傳入dao層，這樣就不符合職責劃分了。
3、同理，不允許dao層的資料傳入到controller/tservice。
總的來說業務分層對於**規範是比較重要，決定著以後的**是否可復用，是否職責清晰，邊界清晰。當然這種分層其實見仁見智, 團隊中的所有人的分層習慣也不同，所以很難權衡出乙個標準的準則，總的來說只要滿足職責邏輯清晰，後續維護容易，就是好的分層。
三層呼叫關係 你真正的了解MVC三層架構開發模式嗎
的確在這些人眼中分層只是乙個形式，前輩們的 這麼寫的，其他專案 這麼寫的，那麼我也這麼跟著寫。但是在真正的團隊開發中每個人的習慣都不同，寫出來的 必然帶著自己的標籤。有的人習慣controller寫大量的業務邏輯，有的人習慣在service中之間呼叫遠端服務，這樣就導致了每個人的開發 風格完全不同，...
MVC 三層架構
mvc開始是存在於桌面程式中的，m是指業務模型，v是指使用者介面，c則是控制器，使用mvc的目的是將m和v的實現 分離，從而使同乙個程式可以使用不同的表現形式。比如一批統計資料可以分別用柱狀圖 餅圖來表示。c存在的目的則是確保m和v的同步，一旦m改變，v應該同步更新。mvc 是一種使用 mvc mo...
MVC三層架構
使用者直接訪問控制層，控制層可以直接運算元據庫 servlet curd 資料庫 弊端 程式十分臃腫，不利於維護，servlet的 中 處理請求，響應，檢視跳轉，處理jdbc，處理業務 處理邏輯 架構 沒有什麼是加一層解決不了的 業務處理 業務邏輯 service 資料持久曾 curd dao vi...