在业务逻辑和数据层看似重叠时分解的最佳设计？
我正在构建一个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服务。
目前我只是设计了这个“常规用户”创建，作为一个概念certificate – 我有一个域对象User ，一个UserDao接口，它有getUser(name)和createUser(User) ，以及一个WebServiceUserDao ，实现UserDao方法并知道如何调用上述七种Web服务方法。 createUser()方法由UserCreationService调用， UserCreationService是我的业务/服务级别类，而后者又由SignupController调用。
但是要扩展这个逻辑以便能够创建不同的用户类型（由User.getType()的不同值表示，我不确定在业务/服务层类和DAO之间绘制线的位置。例如，我应该：
- 每个“用户类型”创建一个
UserDao实现，因此创建每个“用户类型”的逻辑可以封装在它自己的类中，让UserCreationService决定使用哪个UserDao？ 这将对应于1个服务类：许多DAO。 - 我是否应该将
UserDao分解为更小的部分，一个对应于需要在Web服务/ DB中创建的每个“记录”，即使我的整个应用程序不需要知道这些单独类型中的每一个？ 然后为各种不同的“用户类型”提供不同的UserCreationService实现？ 换句话说，即使我不需要相应的Privilege或BillingPlan域对象，此策略也会有PrivilegesDao，BillingPlanDao等。 这将是许多服务类：许多DAO。 - 包含在单个
WebServiceUserDao为每个“用户类型”调用Web服务的所有逻辑？ 这将有一个非常复杂的类的缺点（PMD已经在抱怨圈复杂度），但所有这些逻辑都将封装在一个类中，从整体API角度来看可能会减少复杂性。
我对此应用程序的一个目标是确保如果我们必须更改数据持久性的细节，我们需要做的就是更改DAO实现 – 如果我们必须开始与不同的计费系统连接，除了在DAO级别，我不希望应用程序的任何部分发生更改。
任何意见？ 在决定何时分解“业务逻辑”与“数据访问逻辑”时，您使用什么样的策略？
在决定何时分解“业务逻辑”与“数据访问逻辑”时，您使用什么样的策略？
也许你可以有三层而不是两层：“一个额外的间接层”。
在顶层，您可能拥有不了解数据访问的业务逻辑：此业务层使用User ， Account等类，以及User.getAccounts和Account.getOwners等工厂方法。
底层可能是数据访问层，无论您的数据层是什么，它都是您的包装或外观。
在这两个层之间，一个层知道您的业务对象是什么（例如用户和帐户），而不是您的业务逻辑。 中间层知道您的数据访问层。 中间层的工作是使用数据访问层的API来I / O您的业务对象。
“我不确定在业务/服务层类和DAO之间划分界限的位置。”
我们都不是吗？
我建议使用ORM（ iBatis ， Hibernate ， Toplink等）。 不要实现自己的DAO。