在多层架构中，是否可以跳过业务层进行 crud 操作? [英] In multi-layered architecture, can I skip the business layer for crud operations?

问题描述

我们有 3 层应用程序，其中来自服务层的每个调用都转到业务层并由数据层持久化.每一层的组件只能调用下面的层；

We have 3 layered application where every call from the service layer goes to the business layer and is persisted by the data layer. Components of each layer can only call the layer below;

然而，由于我们有数百个实体，而且我们有很多与 crud 操作相关的服务，因此我们的团队引发了很多争议.

However because we have hundreds of entities and we have lots of services related to crud operations so many controversies raised on our team.

有些人认为，为了维护和开发的方便，最好从只是做 crud 操作并绕过业务层的 crud 服务调用数据访问.

Some believe for the sake of maintenance and ease of development it's better to call data access from crud services which just doing crud operation and bypassing business layer.

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

On the contrary some saying we have to create wrapper for data access of each entity in business layer and call these wrapper from services and never allow services to call data access layer.

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

In your idea which way we should take? Is it ok for crud services to call data accesses and bypassing business layer?

推荐答案

如果没有要执行的业务逻辑，就没有理由强制执行业务层.3 层架构不是一个神秘的协议，只是假设业务处理而形成的最佳实践.

If there is no business logic to perform, there is no reason to enforce a business layer. The 3-tier architecture is not an arcane protocol, just a best practice that was formed assuming business processing.

在当前的应用程序中，当不涉及业务流程时，我们经常直接从 JSF 控制器访问 DAO.这个想法是由 java 冠军 提出的，他强调了简单至上的想法.

In a current application we are often accessing DAOs directly from JSF controllers when there is no business process involved. The idea was given by a java champion who stressed the idea that simplicity is paramount.

如果您担心将来可能需要添加业务逻辑的修改.我是这样想的:额外的业务逻辑无论如何都会被添加到业务层，包括数据访问，所以这里没有区别.

If you are worried about future modifications that may require adding business logic. I think of the issue this way: The additional business logic would be added to the business layer anyway, including data access, so there is no difference here.

CRUD 代码大多非常简单.因此，服务中的更改相当于将来自 DAO 的单个调用或几个调用重新路由到 EJB - 一个简单的重构.CRUD 代码本身仍将保留，但会被推送到 EJB 中——另一个简单的重构.

CRUD code is mostly very simple. So the change in the service would amount to reroute a single call or a couple of calls fron the DAO to an EJB - a simple refactoring. The CRUD code itself would still remain, but will be pushed into the EJB - another simple refactoring.

这并不完美，但 IMO 比替代方案更好:有一个空的间接层.这增加了没有意义的复杂性.业务对象只会将调用转发给 DAO.

This is not perfect, but IMO better then the alternative: having an empty indirection layer. This adds complexity that serves no purpose. The business object would do nothing but forward the calls to the DAO.

我认为有两种代码异味适用于这种情况:人为的复杂性和功能羡慕.

There are two code smells that I think apply in this case: contrived complexity and feature envy.

我并不是说业务层中的 DA 在某种程度上是一种代码气味.我的意思是，拥有一个业务对象除了代理 DAO 之外什么都不做是一种味道.它与复杂性相同 - 添加的数据结构/架构层没有自己的用途 - 您的应用程序中似乎已经有一个 DAL.

I am not saying that DA in the business layer is somehow a code smell. What I mean is that having a business object that does nothing else but proxy the DAO is a smell. It's the same with complexity - an added data structure / architectural layer that serves no own purpose - there seems to be a DAL in your application already.

您需要考虑的另一个方面是 - 开发人员看到直接使用 DAO 的服务有多令人惊讶?有 5 个服务，其中 2 个直接访问 DAO 不同于有 100 个服务，只有一个服务直接访问 DAO.

Another aspect for your consideration would be - how surprising is it for a developer to see a service that uses a DAO directly? Having 5 services where 2 of them access DAO directly is different from having 100 services where only one service accesses the DAOs directly.

在第一种情况下，代码的简单性会超过增加的概念复杂性(单个事物的两个概念)，在第二种情况下，我宁愿坚持使用业务层 - 惊喜(也称为 WTF 效应；)以不同的方式做一次就太大了.

In the first case the code simplicity would outweigh the added conceptual complexity (2 concepts for a single thing), in the second case, I would rather stick with the business layer - the surprise (also called the WTF-effect ;) of doing it differently just once would be too big.

这篇关于在多层架构中，是否可以跳过业务层进行 crud 操作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！