我们有 3 层应用程序，其中来自服务层的每个调用都转到业务层并由数据层持久化。每层的组件只能调用下面的层；
然而，因为我们有数百个实体，并且我们有很多与 crud 操作相关的服务，所以我们的团队引发了很多争议。
有些人认为，为了维护和开发的方便，最好从 crud 服务中调用数据访问，这些服务只是做 crud 操作，绕过业务层。
相反，有人说我们必须为业务层中每个实体的数据访问创建包装器，并从服务中调用这些包装器，并且永远不允许服务调用数据访问层。
您认为我们应该采取哪种方式？crud 服务调用数据访问绕过业务层可以吗？
如果没有要执行的业务逻辑，则没有理由强制执行业务层。3 层架构不是一个神秘的协议，只是假设业务处理形成的最佳实践。
在当前的应用程序中，当不涉及业务流程时，我们经常直接从 JSF 控制器访问 DAO。这个想法是由一位 java 冠军提出的，他强调简单性是最重要的。
如果您担心将来可能需要添加业务逻辑的修改。我是这样考虑问题的：反正额外的业务逻辑会加到业务层，包括数据访问，所以这里没有区别。
CRUD 代码大多非常简单。因此，服务中的更改相当于将 DAO 中的单个调用或几个调用重新路由到 EJB - 一个简单的重构。CRUD 代码本身仍将保留，但将被推入 EJB - 另一个简单的重构。
这并不完美，但 IMO 比替代方案更好：有一个空的间接层。这增加了无用的复杂性。业务对象只会将调用转发给 DAO。
我认为 有两种 代码味道适用于这种情况：人为的复杂性和功能嫉妒。
我并不是说业务层中的 DA 在某种程度上是一种代码味道。我的意思是，拥有一个除了代理 DAO之外什么都不做的业务对象是一种气味。复杂性也是如此 - 添加的数据结构/架构层没有任何用途 - 您的应用程序中似乎已经存在 DAL。
您需要考虑的另一个方面是 - 开发人员看到直接使用 DAO 的服务有多令人惊讶？拥有 5 个服务，其中 2 个直接访问 DAO，不同于拥有 100 个服务，其中只有一个服务直接访问 DAO。
在第一种情况下，代码的简单性将超过增加的概念复杂性（单个事物有两个概念），在第二种情况下，我宁愿坚持业务层 - 这样做的惊喜（也称为 WTF 效应；）只是一次不同会太大。
在我看来，绕过业务层调用 CRUD 服务将在您增加功能时开始将当前服务层转换为业务层。因此，如果您对它没问题，您的服务层也将充当业务层。
在大多数情况下，您处理一个实体，并且可能涉及许多数据层 crud 调用，例如一次更新。为此建议使用业务层。业务层是执行任何业务规则、缓存或在需要时调用其他业务服务的地方。这将保持上层简单并通过。
我不会绕过业务层。尽管看起来您只是将 DAL 的调用代理到 BL 中，并且即使这可能是非常简单的 CRUD 操作的情况，但 BL 可以封装操作所需的验证逻辑。验证逻辑可以在 BL 上执行，并且只有在满足验证条件时才会执行到 DAL 的代理。
如果您只有 CRUD 操作，则可以使用数据服务将数据集发布为 Web 服务。一个很好的例子是 WSO2 数据服务http://wso2.com/products/data-services-server/