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

這是來自阿杰的問題：

大衛(wèi)您好，我想知道我最近遇到的兩種MVC應(yīng)用程序體系結(jié)構(gòu)之間的區(qū)別：

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

謝謝阿杰

好問題！

這兩個選項(xiàng)不是互斥的，實(shí)際上，它們在設(shè)計(jì)良好的Web應(yīng)用程序中是相輔相成的。

您可以將這兩個選項(xiàng)視為垂直和水平分隔。

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

這種分離的原因在于最重要的設(shè)計(jì)原則之一，單一職責(zé)和抽象設(shè)計(jì)模式。

單一責(zé)任

單一責(zé)任原則規(guī)定，任何一個組件都只能對一件事情負(fù)責(zé)（例如：購物車服務(wù)，但是為購物車和報(bào)告提供單一服務(wù)被認(rèn)為是不良設(shè)計(jì)），并且不應(yīng)有其他組件負(fù)責(zé)同一件事行為/狀態(tài)（例如：應(yīng)用程序中功能不相同的購物車服務(wù)不應(yīng)多于一個）。

抽象化

抽象設(shè)計(jì)模式在組件（例如：數(shù)據(jù)庫）之上引入了抽象層（例如：DAO層），同時聲明了有關(guān)應(yīng)用程序其余部分如何通過抽象層與該組件通信的協(xié)定（接口）。

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

另一方面，按模塊（例如，結(jié)帳，購物車）分開是基于業(yè)務(wù)功能的。

這種分離還依賴于“單一責(zé)任”原則和“高內(nèi)聚與耦合”原則。

內(nèi)聚和耦合

內(nèi)聚性是某個模塊的組件如何相互組合的程度。

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。