在多层体系结构中，我可以跳过业务层进行crud操作吗？

作者: CTO啊哦
发布时间: 2024-12-29 04:57:09 (23天前)
转自：

5 条回复

0#
回复此人
一生浮华 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 如果没有要执行的业务逻辑，则没有理由强制执行业务层。 3层架构不是一个神秘的协议，只是假设业务处理形成的最佳实践。 </p> <P> 在当前的应用程序中，当没有涉及业务流程时，我们经常直接从JSF控制器访问DAO。这个想法是由一个 <a href="http://en.wikipedia.org/wiki/Java_Champions" rel="nofollow noreferrer"> java冠军 </A> 他强调简单是至关重要的。 </p> <P> 如果您担心未来可能需要添加业务逻辑的修改。我以这种方式思考问题：无论如何，额外的业务逻辑将被添加到业务层，包括数据访问，因此这里没有区别。 </p> <P> CRUD代码大多非常简单。因此，服务的更改将相当于将DAO中的单个调用或几个调用重新路由到EJB - 一个简单的重构。 CRUD代码本身仍然存在，但将被推入EJB - 另一种简单的重构。 </p> <P> 这不是完美的，但IMO比替代方案更好：拥有一个空的间接层。这增加了无用的复杂性。业务对象只会将调用转发给DAO。 </p> <P> 那里有两个 <a href="http://en.wikipedia.org/wiki/Code_smell" rel="nofollow noreferrer"> 代码闻起来 </A> 我认为适用于这种情况：人为的复杂性和 <a href="http://c2.com/cgi/wiki?FeatureEnvySmell" rel="nofollow noreferrer"> 功能令人羡慕 </A> 。 </p> <P> 我不是说业务层中的DA在某种程度上是代码味道。我的意思是拥有一个业务对象的<strong> 没有其他的 </强> 但代理DAO是一种气味。它与复杂性相同 - 增加了数据结构/架构层，没有任何用途 - 您的应用程序中似乎已经存在DAL。 </p> <P> 另一个需要考虑的方面是 - 开发人员看到直接使用DAO的服务有多令人惊讶？有5个服务，其中2个直接访问DAO不同于有100个服务，其中只有一个服务直接访问DAO。 </p> <P> 在第一种情况下，代码简单性将超过增加的概念复杂性（单个事物的2个概念），在第二种情况下，我宁愿坚持业务层 - 这样做的惊喜（也称为WTF效应;）不同的只是曾经太大了。 </p> </DIV>

编辑
1#
回复此人
NetworkAttachedStorage | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我不会绕过业务层。即使看起来你只是将DAL的调用代理到BL中，即使这可能是非常简单的CRUD操作的情况，BL也可以封装操作所需的验证逻辑。可以在BL上执行验证逻辑，并且仅在满足验证条件时才执行对DAL的代理。 </p> </DIV>

编辑
2#
回复此人
蜡笔小辛 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 如果您只有CRUD操作，则可以使用Data Services将数据集发布为Web服务。一个很好的例子是WSO2数据服务 <a href="http://wso2.com/products/data-services-server/" rel="nofollow"> http://wso2.com/products/data-services-server/ </A> </p> </DIV>

编辑
3#
回复此人
林老爷的日常 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 在我看来，当你增加功能时，绕过业务层调用CRUD服务将开始将当前服务层转换为业务层。因此，如果你对它很好，你的服务层也将充当业务层。 </p> <P> 在大多数情况下，您可以处理一个实体，并且可能涉及许多数据层crud调用，例如，在一个更新上。为此，建议使用业务层。如果需要，业务层可以执行任何业务规则，缓存或调用其他业务服务。这将保持上层简单并通过。 </p> </DIV>

编辑

登录后才能参与评论