使用.NET Core和设计模式编写业务规则

在复杂的业务应用中，高效地实现业务规则对于保持代码的整洁性、避免重复代码以及确保系统的可扩展性至关重要。

在这篇文章中，我们将讨论如何在.NET Core中使用设计模式来实现业务规则，并将其与传统方法进行比较。我们将涵盖实际场景，展示规范模式和责任链模式等设计模式在处理复杂业务规则中的重要性。

照片由 Markus Spiske 拍摄，来源于 Unsplash

一个业务规则是什么？

业务规则是定义了系统中的数据可以被如何处理，并限制了其处理方式的条件和逻辑。

比如：

• 贷款申请： 只有申请人的信用评分超过700分，贷款申请才能被批准。
• 电子商务折扣逻辑： 只有当订单金额超过100美元且用户是会员用户时，才能享受折扣。

这样编写规则时没有结构，往往会导致混乱的代码——嵌套的if语句和散布在多个服务之间的逻辑。

编程中没有设计模式遇到的挑战

当不使用设计模式来实施业务规则时，通常会这样:

• 维护困难: 业务规则与其他逻辑（如UI或服务逻辑）混杂在一起，增加了理解难度。
• 扩展困难: 添加新规则可能需要修改现有代码，从而可能导致错误。
• 测试难题: 规则深嵌在服务或控制器中，使得单元测试变得复杂。

我们来看一下代码。

1: 贷款批准逻辑（不用设计模式）

这种方法的问题：

• 可测试性较差： 添加更多规则会导致此方法内部出现更多条件。
• 违反单一职责原则（SRP）： LoanService 处理多个规则，使得代码更难维护。
• 缺乏灵活性： 如果不同类型的贷款需要不同的规则，我们需要复制或调整逻辑。

重构之道：约定模式

规范模式（Specification Pattern）有助于将业务规则封装成可以重复使用的类，这些类可以按不同方式组合。让我们用这种模式实现同样的贷款审批逻辑。

第一步: 创建规格接口:

步骤 2: 来实施基础规范

第3步: 实现业务规则:

步骤4: 按照规格操作

使用规范设计模式的好处

• 关注点分离： 每个规则都封装在自己的类中。
• 可重用性： 规则可以在不同的服务中复用。
• 可测试性： 每个规则都可以独立测试。
• 可扩展性： 添加新规则无需修改现有逻辑，只需新增规则即可。

示例2：使用责任链模式的订单处理流程

在更高级的场景中，比如电子商务中的订单验证，多个规则需依次运行，每一步可能独立通过或失败。对于这种情况，责任链模式效果很好。

没有责任链机制

这段代码相当简单，但是每个规则都与OrderService紧耦合，缺乏灵活性。

使用责任链模式的代码重构

使用责任链，每个规则变成一个独立的处理者，决定是否继续处理下一条规则。

第一步: 创建处理器接口并实现基本处理器

第二步: 实施具体规则的具体步骤

接下来，配置链

最后，结论部分

使用如 Specification（规范模式）和 Chain of Responsibility（责任链模式）这样的设计模式有助于我们在.NET Core应用程序中编写更干净、更易于维护和扩展的业务逻辑。

与传统的做法相比，这些模式的好处包括：

• 通过将业务规则解耦来提高可维护性。
• 通过将逻辑分割成小型可重用类来提高可测试性。
• 通过允许添加新规则而无需修改现有规则来提高可扩展性。

应用这些模式可能在初期带来一些复杂性，但从长远来看，它们对于业务逻辑经常变化的应用程序来说是值得的。开始使用这些模式来简化代码，并把更多精力集中在实现功能上，而不是把时间花在调试嵌套的 if 语句上！

编程愉快！