Mor*_*Adi 9 architecture web-services java-ee
我们有3层应用程序,每个来自服务层的调用都通过数据层进入业务层和peresist.每层的组件只能调用下面的层;
但是因为我们有数百个实体,而且我们有很多与crud operatins相关的服务,所以我们的团队提出了很多反复无常的事情.
有些人认为,为了维护和易于开发,最好从crud服务调用数据访问,这只是进行crud操作并绕过业务层.
相反,有些人说我们必须为业务层中每个实体的数据访问创建包装器,并从服务中调用这些包装器,永远不允许服务调用数据访问层.
在你的想法中我们应该采取哪种方式？crud服务是否可以调用数据访问并绕过业务层？
如果没有要执行的业务逻辑,则没有理由强制执行业务层.3层架构不是一个神秘的协议,只是假设业务处理形成的最佳实践.
在当前的应用程序中,当没有涉及业务流程时,我们经常直接从JSF控制器访问DAO.这个想法是由一位 java冠军提出的,他强调简单是至关重要的.
如果您担心未来可能需要添加业务逻辑的修改.我以这种方式思考问题:无论如何,额外的业务逻辑将被添加到业务层,包括数据访问,因此这里没有区别.
CRUD代码大多非常简单.因此,服务的更改将相当于将DAO中的单个调用或几个调用重新路由到EJB - 一个简单的重构.CRUD代码本身仍然存在,但将被推入EJB - 另一种简单的重构.
这不是完美的,但IMO比替代方案更好:拥有一个空的间接层.这增加了无用的复杂性.业务对象只会将调用转发给DAO.
我认为在这种情况下有两种 代码气味:设计复杂性和 功能羡慕.
我不是说业务层中的DA在某种程度上是代码味道.我的意思是拥有一个除了代理DAO之外什么都不做的业务对象是一种气味.它与复杂性相同 - 增加了数据结构/架构层,没有任何用途 - 您的应用程序中似乎已经存在DAL.
另一个需要考虑的方面是 - 开发人员看到直接使用DAO的服务有多令人惊讶？有5个服务,其中2个直接访问DAO不同于有100个服务,其中只有一个服务直接访问DAO.
在第一种情况下,代码简单性将超过增加的概念复杂性(单个事物的2个概念),在第二种情况下,我宁愿坚持业务层 - 这样做的惊喜(也称为WTF效应;)不同的只是曾经太大了.
| 归档时间： |
|
| 查看次数： |
1986 次 |
| 最近记录： |