Spring Web应用程序的最大缺陷

在其应用程序中使用Spring Framework的开发人员很好地谈论了依赖注入的好处。不幸的是，他们并不是很好地利用它的好处，例如单一负责的原则和在应用程序中关注点的分离。如果我们看一下任何基于Spring的Web应用程序，很可能会通过使用以下常见且同样错误的设计原则来实现该应用程序：

域模型对象仅用于存储应用程序的数据。换句话说，领域模型遵循贫血领域模型反模式。
业务逻辑位于服务层中，该服务层管理域对象的数据。
服务层对应用程序的每个实体都有一个服务类。

问题是：如果这是如此普遍，那怎么可能是错误的呢？让我们找出答案。

旧习难改

Spring Web应用程序之所以这样看，是因为这是一成不变的方式，旧习惯很难消除，特别是如果它们是由高级开发人员或软件架构师实施的。问题是这些人非常擅长捍卫自己的观点。他们最喜欢的论点之一是，我们的应用程序遵循关注点分离原则，因为它已分为几层，每一层都有特定的职责。

典型的Spring Web应用程序具有以下几层：

Web层负责处理用户的输入并将正确的响应返回给用户。 Web层仅与服务层通信。
充当事务边界的服务层 。它还负责授权，并包含我们应用程序的业务逻辑。服务层管理域模型对象，并与其他服务和存储库层进行通信。
存储库/数据访问层 ，负责与使用的数据存储进行通信。

关注点分离原则定义如下：

关注点分离（Soc）是一种用于将计算机程序分为不同部分的设计原理，这样每个部分都可以解决一个单独的关注点。尽管确实有一个典型的Spring Web应用程序在一定程度上遵循了这一原理，但现实情况是该应用程序具有一个整体的服务层，它承担了太多的责任。更具体地说，服务层有两个主要问题：

首先，从服务层找到应用程序的业务逻辑。

这是一个问题，因为业务逻辑分散在服务层周围。如果我们需要检查特定业务规则的实施方式，则必须首先找到它。这可能并不容易。另外，如果多个服务类别中需要相同的业务规则，则很可能会将规则简单地从一个服务复制到另一个服务。这导致了维护的噩梦。

其次，服务层在每个域模型类中都有一个服务类。

这违反了如下定义的单一责任原则：单一责任原则规定每个类都应具有单一责任，并且该责任应完全由该类封装。它的所有服务都应严格地与这一责任保持一致。

服务类具有很多依赖关系和很多循环依赖关系。典型的Spring Web应用程序的服务层并不由松散耦合的服务组成，这些服务仅具有一种责任。它更像是紧密耦合的整体服务网络。这使得难以理解，维护和重用。这听起来可能有点苛刻，但是服务层通常是Spring Web应用程序中最有问题的部分。对我们来说幸运的是，所有希望都没有丢失。