3

我正在构建一个 MVC Web 应用程序（使用 Spring MVC 框架），我对设计特定区域的最佳方式感到有些困惑。

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

例如，简单地创建一个新用户帐户需要调用总共七种不同的 Web 服务方法来设置必要表中的所有记录（一条user记录、为该用户添加正确privileges的、设置用户的billing详细信息等） .

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

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

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

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

目前我只设计了这个“普通用户”的创建，作为一个概念证明——我有一个域对象User，一个UserDao接口，它有和的方法getUser(name)，createUser(User)以及一个WebServiceUserDao实现UserDao方法并知道如何调用上述内容的接口——提到了七种网络服务方法。该createUser()方法由 a 调用UserCreationService，这是我的业务/服务级别类，而该类又由SignupController.

但是为了扩展这个逻辑以便能够创建不同的用户类型（它们User.getType()由：

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

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

有什么意见吗？当“业务逻辑”和“数据访问逻辑”似乎重叠时，您在决定在哪里分解它们时使用什么样的策略？

4

2 回答 2

7

当“业务逻辑”和“数据访问逻辑”似乎重叠时，您在决定在哪里分解它们时使用什么样的策略？

也许你可以有三层而不是两层：“一个额外的间接级别”。

在顶层，您可能有不了解数据访问的业务逻辑：该业务层使用 、 等类User，Account可能还有一些工厂方法，例如User.getAccounts和Account.getOwners。

底层可能是数据访问层，它是您的包装器或外观，无论您的数据层是什么。

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

于 2009-01-28T14:58:17.670 回答
0

“我不确定在业务/服务层类和 DAO 之间的界限在哪里。”

我们不都是吗？

我建议使用 ORM（iBatis、Hibernate、Toplink等）。不要实现自己的 DAO。

于 2009-01-28T16:00:55.733 回答