分層/分層架構-代碼隔離

Question

從最近幾個月開始，我一直在使用spring-mvc企業應用程序。 我聽說過具有這些層/層的3層體系結構-UI ，業務邏輯和DAO。 我知道這種架構。 但是在從事一些spring-mvc企業項目時，我發現了一些類似這樣的層（基於代碼流）-

 Controller  
    |
    v  
 Service  
    |  
    v
 Manager  
    |  
    v
   Dao  

與三層體系結構相比，我發現上述分層結構有些混亂。 因為我發現在服務層和管理層中都編寫了一些業務邏輯。 混淆可能是由於缺乏護理引起的，或者沒有其他選擇而是這樣做。 但是像3層架構一樣，每層背后可能都有一些原因。 有人可以解釋為什么要使用這些圖層嗎？

基於stackoverflow的規范，這可能不是一個好問題。 但這對於作為像我這樣的新開發人員可以遵循的建議/技巧將很有幫助。
謝謝。

Answer 1

那是MVC（模型-視圖-控制器）體系結構，而不是較舊的（但仍被廣泛使用）數據-業務邏輯-UI模型。 它們只是不同的體系結構模型，盡管它們可以並且可以進行比較和對比，但它們絕對不會一一對應。 如果您發現自己正在從事利用MVC的項目，那么我強烈建議您找到一本有關MVC的書（甚至專門針對Spring-MVC的書）並進行一些學習。

Answer 2

我已經實現了一種與您描述的設計非常相似的設計。 我的理由是“管理器”層將幫助抽象任何特定的數據訪問代碼，使其遠離服務層。

因此，服務看起來像這樣（偽代碼）：

function getCustomer(id) {
    sql = "select * from customer where id = @id";
    return db->execute(sql, id);
}

最終看起來像這樣：

function getCustomer(id) {
   return dbo->getCustomerById(id);
}

這個額外的層為我的項目做了一些事情。 它集中了所有數據訪問，使我可以在其他項目中使用管理器類。 它還為我提供了一個選項（禁止使用天堂），可以更輕松地在不同的數據存儲策略（結構化sql-> nosql）之間進行切換，而無需更改任何服務層代碼。