当业务逻辑和数据层似乎重叠时,分解它们的最佳设计是什么? [关闭]

2024-01-12

我正在构建一个 MVC Web 应用程序(使用 Spring MVC 框架),并且我对设计特定区域的最佳方法有点困惑。

应用程序必须与一系列 Web 服务进行交互,这些服务并不是真正经过精心设计,并且本身没有提供太多抽象 - 基本上,每个创建/更新/检索/删除操作都有一个 Web 服务方法每个“数据类型”,除此之外没有太多的 API。 Web 服务客户端需要知道要调用哪些方法以及以何种顺序调用,以便能够创建所需的数据 - 换句话说,不存在基于“事务”的方法。

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

我正在努力寻找最好的方法来抽象它并将其封装在我们的应用程序中。大多数应用程序都遵循标准流程:

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

在我的应用程序中,我使用自己的一组“域对象”来表示和抽象 Web 服务 WSDL 中定义的数据类型,以便我的域逻辑不依赖于 Web 服务类型,以便我们可以抽象和隐藏无论我们喜欢哪个细节。

我正在寻找一些意见,以设计我上面提到的“用户创建过程”作为示例的最佳方式。正如我所提到的,创建“普通用户”的过程涉及调用七个不同的 Web 服务,但这只是用户的一种“类型” - 我们必须能够创建几种不同类型的用户,每种类型都需要不同的要调用的 Web 服务。

目前我只设计了这个“普通用户”创建,作为概念证明 - 我有一个域对象User, a UserDao接口有以下方法getUser(name) and createUser(User), and a WebServiceUserDao它实现了UserDao方法并知道如何调用上述七个Web服务方法。这createUser()方法被调用UserCreationService,这是我的业务/服务级别类,它又由SignupController.

但是扩展这个逻辑以便能够创建不同的用户类型(它们由不同的值表示)User.getType(),我不确定业务/服务层类和 DAO 之间的界限在哪里。例如,我应该:

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

我对这个应用程序的一个目标是确保如果我们必须更改数据持久性的细节,我们所需要做的就是更改 DAO 实现 - 如果我们必须开始与不同的计费系统进行交互,除了 DAO 级别之外,我不希望应用程序的任何部分发生更改。

有什么意见吗?当“业务逻辑”与“数据访问逻辑”似乎重叠时,在决定在何处分解它们时,您会使用什么样的策略?


当“业务逻辑”与“数据访问逻辑”似乎重叠时,在决定在何处分解它们时,您会使用什么样的策略?

也许您可以拥有三层而不是两层:“一层额外的间接层”。

在顶层,您可能具有不了解数据访问的业务逻辑:该业务层使用类似的类User, Account等等,也许还有一些工厂方法,比如User.getAccounts and Account.getOwners.

底层可能是数据访问层,它是数据层的包装器或外观。

在这两层之间,有一个层知道您的业务对象是什么(例如用户和帐户),但不知道您的业务逻辑是什么。中间层了解您的数据访问层。中间层的工作是使用数据访问层的 API 来 I/O 您的业务对象。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

当业务逻辑和数据层似乎重叠时,分解它们的最佳设计是什么? [关闭] 的相关文章

随机推荐