我的业务逻辑课应该是什么？

Question

我们目前正在就如何构建业务逻辑类进行内部辩论。目前，我们的商业类结构如下：

public class OrderBL
{
    public void CreateOrder(OrderDTO order)
    {
        //save order
        //send email
    }

    public void CancelOrder(OrderDTO order)
    {
        //save order
        //send email
    }

    public void MarkOrderAsDispatched(OrderDTO order)
    {
        //save order
        //send email
    }

    //other private methods too
}

使用我们当前的方法，我们发现类增长非常快，在大型项目上会变得很混乱。

对于我们是否应将业务类别改为如下所示，存在一些争论：

public class CreateOrderBL
{
    public void RunLogic(OrderDTO order)
    {
        CreateOrder();
        SendEmail();
    }

    private voide CreateOrder()
    {

    }

    private void SendEmail()
    {

    }
}

这样做的好处是，类更容易理解，而且很小，但缺点是类的数量增加。

有什么正确的方法来处理这个问题呢？

Answer 1

“正确”的方法是最有效地满足应用程序在可维护性、性能等方面的非功能性需求的方法。

您需要的是业务逻辑层( Business，简称服务层 )。这些层将CRUD方法转换为实际的业务操作。是的，您将拥有更多的类，但是这些类将得到更好的组织和更好的关注点分离。

我会避免大量使用Execute()风格的方法。将类分组到业务聚合(如OrderProcessing或Shipping )中，并为您的方法指定有意义的名称，如ProcessOrder() (调用CreateOrder和SendEmail)。

Answer 2

您正在考虑从面向业务对象的模型转移到面向业务操作/事务的模型。许多事务性系统都建立在这种方法的基础上。

但是，如何保持面向对象方法的优势呢？挑战将是保持秩序内部的某个地方的跟踪。并控制外部世界这些内部的可见度。

所以你不仅会有越来越多的课程。但是，您还可以显著增加类之间的交互，例如，CreatOrderBL和一些OrderBL之间的交互，后者必须保持内部状态，并最终管理对象的持久性。

结论:根据定义，您将增加您的模型的复杂性。要理解一个更简单的类，您需要对所有相关类有一个很好的理解。

Answer 3

“正确”是主观的，每个人都会对“正确”的含义有自己的看法。在我看来，正确意味着代码可以工作，并且易于维护和扩展。我更喜欢将工作流、操作和实体分开的设计模式。

在本例中，" order“是一个实体，操作是人们可以使用order (CRUD)所做的事情，而工作流是编排操作以实现业务结果的业务逻辑。理想情况下，您不希望业务逻辑直接操作实体，而只依赖于“操作”层(该层知道如何相应地操作实体)。

原因在于，随着时间的推移，您可以合理地预期"order“对象会发生变化，例如，它可能从一个数据库平台迁移到另一个数据库平台。如果业务逻辑与实体对象分离，您就可以适应对order对象的更改，而不必对业务逻辑层进行大修。

按照同样的想法，设计这样的业务逻辑层将是合理的，这样您的业务逻辑层就不会触及任何东西，并且总是经过“适配器”层。例如，如果您的电子邮件系统被更改，发送电子邮件的代码将需要重新访问。

由于这些原因，我喜欢第二种设计，而不是第一种。在当前(顶级)设计中，当订单系统和/或电子邮件和/或持久化(数据库)层发生变化时，您的业务逻辑中有很多地方需要相应更改。这将阻碍适应变化的灵活性，并增加更改应用程序以响应业务需求所需的复杂性。