java – 在业务逻辑和数据层看起来重叠时分解它们的最佳设计？
作者：互联网
我正在构建一个MVC Web应用程序(使用Spring MVC框架),我对设计特定区域的最佳方法感到有些困惑.
应用程序必须与一系列Web服务进行交互,这些Web服务并非真正设计得非常完美,并且本身并不提供很多抽象 – 基本上每个创建/更新/检索/删除操作都有一个Web服务方法.每个“数据类型”,除此之外没有太多的API. Web服务客户端需要知道要调用哪些方法,以及能够以何种顺序创建所需的数据 – 换句话说,没有基于“事务”的方法.
例如,只需创建一个新的用户帐户,就需要调用总共七种不同的Web服务方法来设置必要表中的所有记录(用户记录,为该用户添加正确的权限,设置用户的帐单明细等).
我正在努力用最好的方法来抽象它并将其封装在我们的应用程序中.大多数应用程序遵循标准流程：
request ---> Controller <---> Service/Business-level object <---> DAOs for data access
在我的应用程序中,我使用自己的一组“域对象”来表示和抽象Web服务WSDL中定义的数据类型,这样我的域逻辑就不依赖于Web服务类型,因此我们可以抽象和隐藏我们喜欢哪个细节.
我正在寻找一些意见是设计上面提到的“用户创建过程”的最佳方法.创建“常规用户”的过程涉及调用七种不同的Web服务,如我所提到的,但这只是用户的一种“类型” – 我们必须能够创建几种不同类型的用户,每种用户需要不同的要调用的Web服务.
目前我只是设计了这个“常规用户”创建,作为一个概念证明 – 我有一个域对象User,一个UserDao接口,它有getUser(name)和createUser(User)的方法,以及一个WebServiceUserDao,实现UserDao方法并知道如何调用上述七种Web服务方法. createUser()方法由UserCreationService调用,UserCreationService是我的业务/服务级别类,而后者又由SignupController调用.
但是要扩展此逻辑以便能够创建不同的用户类型(由User.getType()中的不同值表示,我不确定在业务/服务层类和DAO之间绘制线的位置.例如,我应该：
>为每个“用户类型”创建一个UserDao实现,因此创建每个“用户类型”的逻辑可以封装在它自己的类中,让UserCreationService决定使用哪个UserDao？这将对应于1个服务类：许多DAO.
>我是否应该将UserDao分成更小的部分,一个对应于需要在Web服务/数据库中创建的每个“记录”,即使我的整个应用程序不需要知道这些个别类型中的每一个？然后为各种不同的“用户类型”提供不同的UserCreationService实现？换句话说,即使我不需要相应的Privilege或BillingPlan域对象,此策略也会有PrivilegesDao,BillingPlanDao等.这将是许多服务类：许多DAO.
>包含在单个WebServiceUserDao中为每个“用户类型”调用Web服务的所有逻辑？这将具有非常复杂的缺点
class(并且PMD已经在抱怨圈复杂度),但所有这些逻辑都将封装在一个类中,从整体API角度来看,可能会减少复杂性.
我对此应用程序的一个目标是确保如果我们必须更改数据持久性的详细信息,我们需要做的就是更改DAO实现 – 如果我们必须开始与不同的计费系统连接,我不希望应用程序的任何部分在DAO级别之外进行更改.
任何意见？在决定何时分解“业务逻辑”与“数据访问逻辑”时,您使用什么样的策略？
解决方法:
What kind of strategies do you use when deciding where to break down “business logic” versus “data access logic” when they seem to overlap?
也许你可以有三层而不是两层：“一个额外的间接层”.
在顶层,您可能拥有不了解数据访问的业务逻辑：此业务层使用User,Account等类,以及User.getAccounts和Account.getOwners等工厂方法.
底层可能是数据访问层,它是您的数据层的包装或外观.
在这两个层之间,一个层知道您的业务对象是什么(例如用户和帐户),而不是您的业务逻辑.中间层知道您的数据访问层.中间层的工作是使用数据访问层的API来I / O您的业务对象.
标签：business-logic,java,model-view-controller,data-access-layer 来源： https://codeday.me/bug/20190730/1585251.html