Spring应用架构

我最近收到我博客的一位读者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