在多层体系结构中，我是否可以跳过业务层以实现crud操作？

Question

我们有3个分层的应用程序，其中每个来自服务层的调用都通过数据层进入业务层和peresist。 每层的组件只能调用下面的图层;

但是，因为我们有数百个实体，并且我们有很多与crud operatins相关的服务，所以我们团队中提出了许多内容。

一些人认为，为了维护和易于开发，最好从粗劣服务调用数据访问，这些服务只是在进行粗劣操作并绕过业务层。

相反，有些人说我们必须为业务层中的每个实体的数据访问创建包装，并从服务调用这些包装，并且绝不允许服务调用数据访问层。

在你的想法中我们应该采取哪种方式？ crud服务可以调用数据访问并绕过业务层吗？

Answer 1

如果没有业务逻辑可执行，则没有理由执行业务层。三层体系结构不是一个神秘的协议，只是业务处理过程中形成的最佳实践。

在当前的应用程序中，我们经常在没有涉及业务流程的情况下直接从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效应; ）以不同的方式做一次就太大了。

Answer 2

如果您只有CRUD操作，则可以使用Data Services将数据集发布为Web服务。一个很好的例子是WSO2数据服务http://wso2.com/products/data-services-server/

Answer 3

在我看来，呼叫CRUD服务绕过业务层将开始将当前服务层转换为业务层，同时增加功能。所以你的服务层也会充当业务层，如果你没有问题的话。

在大多数情况下，您处理一个实体，可能涉及到多个数据层crud调用，例如一次更新。为此推荐业务层。业务层是执行任何业务规则，缓存或调用其他业务服务的地方。这将保持上层简单并通过。

Answer 4

我不会绕过业务层。即使它看起来像只是将DAL的调用代理到BL中，并且即使这可能是非常简单的CRUD操作的情况，BL也可以封装操作所需的验证逻辑。验证逻辑可以在BL上执行，并且只有验证条件满足时才会执行代理到DAL。