Tag: 业务逻辑

在业务逻辑和数据层看似重叠时分解的最佳设计？

我正在构建一个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级别，我不希望应用程序的任何部分发生更改。 任何意见？ 在决定何时分解“业务逻辑”与“数据访问逻辑”时，您使用什么样的策略？

我想，我需要一个简单的规则引擎？

我需要一些关于解决这个问题的最佳方法的建议。 我研究过DROOLS，Java Rule Engine和其他一些。 所有这些都是强大的，并且对它们有好处。 我不知道哪个（如果有的话）对我来说是最好的选择。 我有一个业务对象。 （简化演示） Person firstName:String lastName:String departMent:String hireDate:Date 我需要在Web应用程序中编写一个编辑器，以便围绕这些字段构建复杂的规则。 我需要支持复杂的嵌套AND / OR逻辑。 我只需要基本的运算符，规则应该简单地评估为真或假。 如果规则评估为true或false，则将分别执行一个操作。 例如， firstName CONTAINS“value”AND（lastName EQUALS“input”OR department CONTAINS“input”） 我曾经想过，也许我应该编写自己的解析器并在我自己的代码中评估逻辑。 我不知道该怎么做，任何建议或链接到阅读的东西将不胜感激。 我可以研究一种特定的设计模式吗？ 你怎么解决这个问题？ 关于规则引擎的一个保留意见是，它们可能过于复杂而不仅仅是一个简单的问题？

将业务逻辑放在spring mvc框架中的哪里？

我不知道将业务逻辑放在spring mvc中的哪个位置因为我是新手。 我知道该做什么，但由于缺乏春季mvc的知识，我不知道从哪里开始。 我还想问一下，如果有人知道我可以在哪里获得一个很好的教程，或者有一个具有业务逻辑的spring mvc web应用程序的完整示例？ 无论如何，我所谈论的业务逻辑都是关于数据库处理:)