我最近收到我博客的一位讀者Ajay的問題，并決定在此處分享我的答案，以幫助其他有類似問題的人。

這是來自阿杰的問題：

大衛您好，我想知道我最近遇到的兩種MVC應用程序體系結構之間的區別：

1）在普通的Spring MVC教程中使用的...模型，視圖，控制器，配置，DAO和資源。
2）更精細的架構，其中將應用程序分為模塊（例如，結帳，購物車），每個模塊都有自己的包，其中包含控制器，服務接口，服務Impl和實體/模型。

謝謝阿杰

好問題！

這兩個選項不是互斥的，實際上，它們在設計良好的Web應用程序中是相輔相成的。

您可以將這兩個選項視為垂直和水平分隔。

在討論按模型，視圖，控制器，配置，DAO等進行的分離時，我們討論基于應用程序的不同層和組件。
技術（邏輯）設計。

這種分離的原因在于最重要的設計原則之一，單一職責和抽象設計模式。

單一責任

單一責任原則規定，任何一個組件都只能對一件事情負責（例如：購物車服務，但是為購物車和報告提供單一服務被認為是不良設計），并且不應有其他組件負責同一件事行為/狀態（例如：應用程序中功能不相同的購物車服務不應多于一個）。

抽象化

抽象設計模式在組件（例如：數據庫）之上引入了抽象層（例如：DAO層），同時聲明了有關應用程序其余部分如何通過抽象層與該組件通信的協定（接口）。

這樣可以更輕松地替換合同的基礎實現（例如：您的DAO層現在可以使用JPA，但是明天您可以以相對較小的努力將其切換到Elasticsearch或Neo4j）。

另一方面，按模塊（例如，結帳，購物車）分開是基于業務功能的。

這種分離還依賴于“單一責任”原則和“高內聚與耦合”原則。

內聚和耦合

內聚性是某個模塊的組件如何相互組合的程度。

耦合度是指多少組件了解彼此的內部工作情況。

當您根據業務功能將模塊分為不同的包時，將來可以更輕松地將這些模塊重構為它們自己的微服務（Web應用程序）。 這樣，他們每個人都可以擁有自己的部署生命周期，并且可以獨立擴展。

翻譯自: https://www.javacodegeeks.com/2018/08/spring-application-architectures.html

總結

以上是生活随笔為你收集整理的Spring应用架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。