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