当业务逻辑和数据层看起来重叠时，用于分解业务逻辑和数据层的最佳设计? [英] Best designs for breaking down business logic and data layer when they seem to overlap?

问题描述

我正在构建一个MVC Web应用程序(使用Spring MVC框架)，而我对设计特定区域的最佳方法有些困惑.

I'm building a MVC web application (using the Spring MVC framework), and I'm a little stumped on the best way to design a particular area.

应用程序必须与一系列Web服务进行交互，而这些Web服务并不是真正设计得很好，并且本身并不能提供太多抽象-基本上，每种创建/更新/检索/都有一个Web服务方法.删除每个数据类型"的操作，除此之外没有太多的API. Web服务客户端需要知道要调用哪些方法以及以哪种顺序才能创建它需要的数据，换句话说，没有基于事务"的方法.

The application has to interact with a series of web services which are not really all that greatly designed, and don't offer much abstraction in and of themselves - basically there is a web service method for each create/update/retrieve/delete operation for each "datatype", and there isn't much of an API beyond that. The web service client needs to know which methods to invoke, and in which order, to be able to create the data it needs to - in other words, there are no "transaction" based methods.

例如，仅创建一个新用户帐户就需要调用总共七个不同的Web服务方法来设置必要表中的所有记录(user记录，向该用户添加正确的privileges ，设置用户的billing详细信息等).

For example, simply to create a new user account requires calling a total of seven different web service methods to set up all of the records in the necessary tables (a user record, adding the correct privileges to that user, setting up the user's billing details, etc).

我正在努力将其抽象并将其封装在我们的应用程序中的最佳方法.大多数应用程序遵循标准流程:

I'm struggling with the best way to abstract this and encapsulate it within our application. Most of the app follows a standard flow:

request ---> Controller <---> Service/Business-level object <---> DAOs for data access

在我的应用程序中，我使用自己的一组域对象"来表示和抽象化Web服务WSDL中定义的数据类型，因此我的域逻辑不依赖于Web服务类型，因此我们可以提取并隐藏我们喜欢的任何细节.

Within my application, I'm using my own set of "domain objects" to represent and abstract the datatypes defined in the web service WSDL, so that my domain logic is not dependent on the web service types and so that we can abstract and hide whichever details we like.

我要寻找的是我上面作为示例设计用户创建过程"的最佳方法.正如我所提到的，创建常规用户"的过程涉及调用七个不同的Web服务，但这只是一种类型"的用户-我们将必须能够创建几种不同类型的用户，每种类型需要不同的用户要调用的Web服务.

What I'm looking for some opinions on is the best way to design the "user creation process" I mentioned above as an example. The process to create a "regular user" involves calling seven different web services, as I mentioned, but this is just one "type" of user - we will have to be able to create several different types of users, each of which require different web services to be invoked.

当前，我仅设计了这种常规用户"创建，作为概念证明-我有一个域对象User，一个UserDao接口，其中包含用于getUser(name)和createUser(User)的方法，以及实现UserDao方法并知道如何调用上述七个Web服务方法的WebServiceUserDao. createUser()方法由UserCreationService调用，这是我的业务/服务级别的类，而该类又由SignupController调用.

Currently I've only designed this "regular user" creation, as a bit of a proof of concept - I have a domain object User, a UserDao interface which has methods for getUser(name) and createUser(User), and a WebServiceUserDao which implements the UserDao methods and knows how to invoke the above-mentioned seven web service methods. The createUser() method is called by a UserCreationService, which is my business/service-level class, which in turn is invoked by the SignupController.

但是为了扩展此逻辑以便能够创建不同的用户类型(在User.getType()中由不同的值表示)，我不确定在业务/服务层类与DAO之间的界限如何例如，我应该:

But to expand this logic in order to be able to create the different user types (which are represented by different values in User.getType(), I'm unsure where to draw the line between the business/service layer class and the DAO. For instance, should I:

1. 为每个用户类型"创建一个UserDao实现，因此可以将创建每个用户类型"的逻辑封装在其自己的类中，然后让UserCreationService决定使用哪个UserDao?这将对应于一种服务类别:许多DAO.
2. 我应该将UserDao分解成较小的部分，对应于需要在Web服务/DB中创建的每个记录"，即使我的整个应用程序不需要了解每种单独的类型?然后对于各种不同的用户类型"有不同的UserCreationService实现吗?换句话说，即使我不需要相应的Privilege或BillingPlan域对象，该策略也将具有PrivilegesDao，BillingPlanDao等.这将是许多服务类别:许多DAO.
3. 在单个WebServiceUserDao中包含需要为每个用户类型"调用Web服务的所有逻辑吗?这将具有非常复杂的缺点 类(并且PMD已经在抱怨循环复杂性)，但是所有这些逻辑都将封装在一个类中，并且从总体API角度来看，可能会减少复杂性.

1. Create one UserDao implementation per "user type", so the logic to create each "user type" can be encapsulated in it's own class, and let the UserCreationService decide which UserDao to use? This would correspond to 1 service class : many DAOs.
2. Should I break the UserDao into smaller pieces, one corresponding to each "record" that needs to be created in the web service / DB, even though my overall application doesn't need to know about each of these individual types? And then have different UserCreationService implementations for the various different "user types"? In other words, this strategy would have a PrivilegesDao, a BillingPlanDao, etc., even though I would have no need for a corresponding Privilege or BillingPlan domain object. This would be many service classes : many DAOs.
3. Contain all of the logic for which web services need to be called for each "user type" in a single WebServiceUserDao? This would have the drawback of having a very complicated class (and PMD is already complaining about cyclomatic complexity), but all of this logic would be encapsulated in the one class and might lead to less complication when viewed from an overall API perspective.

此应用程序的一个目标是确保，如果我们不得不更改数据持久性的详细信息，那么我们要做的就是更改DAO实现-如果我们必须开始与其他DAO进行接口计费系统，除了DAO级别外，我不想更改应用程序的任何部分.

One goal that I have with this application is to make sure that if we ever have to change the details of the data persistence, that all we need to do is change the DAO implementations - if we have to start interfacing with a different billing system, I don't want any part of the application to change other than at the DAO-level.

有什么意见吗?在确定业务逻辑"与数据访问逻辑"之间似乎重叠时，该使用哪种策略?

Any opinions? What kind of strategies do you use when deciding where to break down "business logic" versus "data access logic" when they seem to overlap?

推荐答案

当确定业务逻辑"与数据访问逻辑"之间似乎重叠时，该使用哪种策略?

What kind of strategies do you use when deciding where to break down "business logic" versus "data access logic" when they seem to overlap?

也许您可以拥有三层而不是两层:一个额外的间接层".

Maybe you can have three layers instead of two: "one extra level of indirection".

在顶层，您可能具有不了解数据访问的业务逻辑:此业务层使用诸如User，Account等之类的类，也许还使用诸如User.getAccounts和Account.getOwners.

At the top layer, you might have business logic which doesn't know about data-access: this business layer uses classes like User, Account, etc., and maybe some factory methods like User.getAccounts and Account.getOwners.

最底层可能是数据访问层，它是数据层所在的包装或外观.

The bottom layer might be a data-access layer, which is your wrapper around or facade to whatever your data layer is.

在这两层之间，一层知道您的业务对象是什么(例如，用户和帐户)，但不知道您的业务逻辑是什么.中间层知道您的数据访问层.中间层的工作是使用数据访问层的API对业务对象进行I/O.

Between these two layers, a layer which knows what your business objects are (e.g. User and Account) but not what your business logic is. The middle layer knows your data access layer. The job of your middle layer is to use your data access layer's API to I/O your business objects.

这篇关于当业务逻辑和数据层看起来重叠时，用于分解业务逻辑和数据层的最佳设计?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！