在 C# 中使用属性或方法公开业务规则？

Question

我正在编写一个类来封装一些业务规则，每个规则都由一个布尔值表示。该类将用于处理 InfoPath 表单，因此规则通过使用 XPath 操作在全局 XML 数据结构中查找值来获取当前程序状态。将这些规则公开给调用者的最佳（最惯用）方式是什么——属性还是公共方法？

使用属性调用

Rules rules = new Rules();
if ( rules.ProjectRequiresApproval ) {
    // get approval
} else {
    // skip approval
}

使用方法调用

Rules rules = new Rules();
if ( rules.ProjectRequiresApproval() ) {
    // get approval
} else {
    // skip approval
}

规则类将规则公开为属性

public class Rules() {
    private int _amount;
    private int threshold = 100;

    public Rules()  {
        _amount = someExpensiveXpathOperation;
    }

    // rule property
    public bool ProjectRequiresApproval {
        get { return _amount > threshold }
    }
}

规则类将规则公开为方法

public class Rules() {
    private int _amount;
    private int threshold = 100;

    public Rules()  {
        _amount = someExpensiveXpathOperation;
    }

    // rule method
    public bool ProjectRequiresApproval() {
        return _amount > threshold;
    }
}

优点是什么以及其中一种相对于另一种的缺点？

Answer 1

这一切都归结为向使用该业务逻辑的人传达语义。

属性是特定对象的内在价值。您的示例中的 Rules 是一个业务逻辑引擎，因此它公开的任何属性都应应用于该引擎的状态和行为，而不是应用于它处理的数据。因此，ProjectRequiresApproval() 是引擎应用于外部实体的操作。

另一方面，如果有 Rules.GetProcess() 方法，它将返回一个 Process 对象，RequiresAproval 可以是该对象的属性。

Answer 2

首先，您需要将 get{} 包装在属性逻辑周围，并且经验法则（无论如何对我来说）应该是方法可以更改类的内容，或执行某种业务逻辑，而属性公开有关班级的信息。

对于您的使用，我建议使用一个属性，因为值已经存在，并且您正在创建所谓的派生属性。

另外，您的代码可以重构为

return _amount < threshold;

Answer 3

我同意安东尼·科赫的观点。当我需要执行更改类状态的复杂计算时，我会使用方法。如果需要对类的当前状态进行简单的计算或数据检索，并且数据已存在于该状态并且不需要更改，则属性似乎更合适。

Answer 4

根据属性与方法 MSDN 上的指南（诚然适用于旧版本的 Visual Studio），听起来方法可能比您的情况更适合您的情况（假设规则比阈值更复杂）。

对这个问题的更多研究揭示了以下内容：

• Ken Browning 关于属性与属性的优秀答案一般方法
• 博客文章 Bill Wagner（《Effective C#》的作者）介绍了使用属性时应满足哪些条件
• 几个开源规则引擎的链接 (NxBRE 和 Drools.NET），这样你就可以看到实施业务规则的替代方案。

Answer 5

这是一个真实的例子吗？我问这个问题是因为我觉得规则对象可能有金额和阈值很奇怪。我提到这一点是因为我认为这是答案的一部分。我认为您的规则是一个命名空间，项目是一个对象，在我看来，是否需要批准将是项目类的属性。