我们有 3 层应用程序，其中来自服务层的每个调用都转到业务层并由数据层持久化。每层的组件只能调用下面的层；
然而，因为我们有数百个实体，并且我们有很多与 crud 操作相关的服务，所以我们的团队引发了很多争议。
有些人认为，为了维护和开发的方便，最好从 crud 服务中调用数据访问，这些服务只是做 crud 操作，绕过业务层。
相反，有人说我们必须为业务层中每个实体的数据访问创建包装器，并从服务中调用这些包装器，并且永远不允许服务调用数据访问层。
您认为我们应该采取哪种方式？ crud 服务调用数据访问绕过业务层可以吗？
最佳答案
如果没有要执行的业务逻辑，则没有理由强制执行业务层。 3 层架构不是一个神秘的协议(protocol)，只是假设业务处理形成的最佳实践。
在当前的应用程序中，当不涉及业务流程时，我们经常直接从 JSF Controller 访问 DAO。这个想法是由 java champion 给出的。谁强调简单是最重要的想法。
如果您担心将来可能需要添加业务逻辑的修改。我是这样考虑问题的:反正额外的业务逻辑会加到业务层，包括数据访问，所以这里没有区别。
CRUD 代码大多非常简单。因此，服务中的更改相当于将 DAO 中的单个调用或几个调用重新路由到 EJB - 一个简单的重构。 CRUD 代码本身仍将保留，但将被插入 EJB - 另一个简单的重构。
这并不完美，但 IMO 比替代方案更好:有一个空的间接层。这增加了无用的复杂性。业务对象只会将调用转发给 DAO。
有两个code smells我认为适用于这种情况:人为的复杂性和feature envy .
我并不是说业务层中的 DA 在某种程度上是一种代码味道。我的意思是拥有一个可以执行 的业务对象。没有别的但是代理DAO是一种气味。复杂性也是如此——添加的数据结构/架构层没有任何用途——您的应用程序中似乎已经存在 DAL。
您需要考虑的另一个方面是 - 开发人员看到直接使用 DAO 的服务有多令人惊讶？拥有 5 个服务，其中 2 个直接访问 DAO，不同于拥有 100 个服务，其中只有一个服务直接访问 DAO。
在第一种情况下，代码的简单性将超过增加的概念复杂性(单个事物有两个概念)，在第二种情况下，我宁愿坚持业务层 - 这样做的惊喜(也称为 WTF 效应；)只是一次不同会太大。
关于web-services - 在多层架构中，是否可以跳过业务层进行 crud 操作？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16211858/