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

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

应用程序必须与一系列web服务交互,这些web服务实际上并不是设计得很好,本身也没有提供太多抽象-基本上,对于每个“数据类型”,每个创建/更新/检索/删除操作都有一个web服务方法,除此之外没有太多API。web服务客户端需要知道要调用哪些方法,以及以何种顺序创建所需的数据——换句话说,没有基于“事务”的方法。

例如,简单地创建一个新的用户帐户需要调用总共七种不同的web服务方法来设置必要表中的所有记录(a user 记录,添加正确的 privileges 对于该用户,设置用户的 billing 细节等)。

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

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

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

我正在寻找的一些意见是设计我上面提到的“用户创建过程”的最佳方式。正如我提到的,创建“常规用户”的过程涉及调用七个不同的web服务,但这只是一种“类型”的用户——我们必须能够创建几种不同类型的用户,每种类型都需要调用不同的web服务器。

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

但是,为了扩展此逻辑,以便能够创建不同的用户类型(由中的不同值表示) User.getType() ,我不确定在哪里划分业务/服务层类和DAO。例如,我应该:

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

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

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