我们有 3 层应用程序，其中来自服务层的每个调用都进入业务层并由数据层保存。每层组件只能调用下面的层；
然而，由于我们有数百个实体，并且有很多与 CRUD 操作相关的服务，因此我们的团队引发了很多争议。
有些人认为，为了维护和易于开发，最好从 CRUD 服务调用数据访问，该服务只进行 CRUD 操作并绕过业务层。
相反，有人说我们必须为业务层中每个实体的数据访问创建包装器，并从服务调用这些包装器，并且永远不允许服务调用数据访问层。
您认为我们应该采取哪种方式？ CRUD服务可以调用数据访问并绕过业务层吗？
如果没有要执行的业务逻辑，就没有理由强制执行业务层。三层架构并不是一个神秘的协议，只是假设业务处理而形成的最佳实践。
在当前的应用程序中，当不涉及业务流程时，我们经常直接从 JSF 控制器访问 DAO。这个想法是由一个爪哇冠军 http://en.wikipedia.org/wiki/Java_Champions他强调简单性是最重要的理念。
如果您担心将来可能需要添加业务逻辑的修改。我是这样想的：额外的业务逻辑无论如何都会添加到业务层，包括数据访问，所以这里没有区别。
CRUD 代码大多非常简单。因此，服务中的更改相当于将 DAO 的单个调用或几个调用重新路由到 EJB - 一个简单的重构。 CRUD 代码本身仍将保留，但将被推送到 EJB 中 - 另一个简单的重构。
这并不完美，但在我看来比替代方案更好：有一个空的间接层。这增加了没有任何意义的复杂性。业务对象除了将调用转发到 DAO 之外什么也不做。
那里有两个代码异味 http://en.wikipedia.org/wiki/Code_smell我认为适用于这种情况：人为的复杂性和特征羡慕 http://c2.com/cgi/wiki?FeatureEnvySmell.
我并不是说业务层中的 DA 有某种代码味道。我的意思是拥有一个业务对象没有其他的但代理DAO是有味道的。复杂性也是如此 - 添加的数据结构/架构层没有自己的用途 - 您的应用程序中似乎已经有一个 DAL。
您需要考虑的另一个方面是 - 对于开发人员来说，看到直接使用 DAO 的服务有多令人惊讶？拥有 5 个服务（其中 2 个直接访问 DAO）与拥有 100 个服务（其中只有一个服务直接访问 DAO）不同。
在第一种情况下，代码的简单性将超过增加的概念复杂性（单个事物有两个概念），在第二种情况下，我宁愿坚持业务层 - 这样做的惊喜（也称为 WTF 效果；）不同的是，只有一次就太大了。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
