在上下文中抽象数据以处理未来的对象类型（策略设计模式）？答案

【问题标题】：Abstracting Data in Context to deal with future object type (Strategy design pattern)?在上下文中抽象数据以处理未来的对象类型（策略设计模式）？
【发布时间】：2011-03-11 04:07:07
【问题描述】：

我必须设计一个数据验证框架，它基本上分解在这些组件中。

数据访问器 - 最好的方法是什么处理这个
对象构建器 - 我应该如何为未来做准备对象结构
验证器（策略模式）

我必须对数据应用一些规则，但我不知道该数据集将来会是什么样子。

所以在思考了很多规则是否应该知道对象的外观或者是否有可能在没有规则和数据依赖的情况下，我感到困惑（我有一种感觉，是的，但是不知道如何）。我发现很难为数据集设计抽象。

任何线索，我应该朝哪个方向思考？

语言 - C# (.NET)
平台 - Windows

编辑：确切的问题

在策略模式中，上下文是否可以保存通用对象，策略可以处理它，而不知道对象是如何构造的？

【问题讨论】：

关于你的旗帜，我相信这对将来的某些人可能有用。

标签： c# design-patterns

【解决方案1】：

在验证框架中，您通常有一组“开箱即用”的规则，它们对对象/实体的外观一无所知。例如，您可能有一个 NotNullRule 来检查给定属性是否为空：

//code is not REAL code!

var user = new User({username=null, email="hello@test.com");
var notNullrule = new NotNullRule( typeof(User).GetProperty("username"), user );
var errors = notNullrule.Check();
Debug.Assert( errors[0] == "Property Username cannot be null");

通常使用属性来设置对类的哪些属性使用哪种验证策略。见this example here。

验证框架通常也允许您创建自定义规则，这可能是特定于域的。例如：

public class CustomerIsEligibleForDiscount : Rule
{ 
    public void Check(){ ... }
}

希望这会有所帮助。

【讨论】：

【解决方案2】：

如果您定义了一个在必要时调用抽象 ValidateRules() 方法的抽象/基类，那么您可以在从抽象/基类继承的每个类中实现 ValidateRules()。

在基类中将方法声明为抽象会强制其在任何派生类中实现。

【讨论】：

【解决方案3】：

您是否有任何理由不能使用众多现有 C# 验证框架之一作为起点？他们往往有内置的约定来处理这些问题。

【讨论】：