当它们看起来重叠时,分解业务逻辑和数据层的最佳设计？

我正在构建一个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(),我不确定在业务/服务层类和DAO之间绘制线的位置.例如,我应该:

UserDao每个"用户类型" 创建一个实现,因此创建每个"用户类型"的逻辑可以封装在它自己的类中,并让UserCreationService决定UserDao使用哪个？这将对应于1个服务类:许多DAO.

我是否应该UserDao分成小块,一个对应于需要在Web服务/ DB中创建的每个"记录",即使我的整个应用程序不需要知道这些单独类型中的每一个？然后UserCreationService针对各种不同的"用户类型" 进行不同的实现？换句话说,即使我不需要对应的或域对象,这个策略也会有a PrivilegesDao,a BillingPlanDao等.这将是许多服务类:许多DAO.PrivilegeBillingPlan

包含需要为单个中的每个"用户类型"调用Web服务的所有逻辑WebServiceUserDao？这将有一个非常复杂的类的缺点(PMD已经在抱怨圈复杂度),但所有这些逻辑都将封装在一个类中,从整体API角度来看可能会减少复杂性.

我对此应用程序的一个目标是确保如果我们必须更改数据持久性的详细信息,我们需要做的就是更改DAO实现 - 如果我们必须开始与不同的计费系统连接,我不希望应用程序的任何部分在DAO级别之外进行更改.

任何意见？在决定何时将"业务逻辑"与"数据访问逻辑"分解时,您使用什么样的策略？

在决定何时将"业务逻辑"与"数据访问逻辑"分解时,您使用什么样的策略？

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

在顶层,你可能有业务逻辑不知道数据访问:该业务层使用类,如User,Account等,也许有些工厂方法,如User.getAccounts和Account.getOwners.

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

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