如何使用 DI 通过 IValidatableObject 接口向实体提供验证器？答案

【问题标题】：How can I use DI to provide a validator to an entity via IValidatableObject interface?如何使用 DI 通过 IValidatableObject 接口向实体提供验证器？
【发布时间】：2013-03-27 08:21:23
【问题描述】：

我的业务层有实现 IValidatableObject 的对象。我希望这些实体在外部程序集中的业务规则，然后调用类型的验证器：

public IEnumerable<ValidationResult> Validate(ValidationContext vc){}

我打算使用 DI 将验证器注入到实现 IValidatableObject 接口的类型的构造函数中。

   public Customer(ICustomerValidator validator)
        {
            this.Validator = validator;
        }

我想我会在类型工厂中调用 Unity 并从那里注入。

但是很多时候实体只是读取而不是修改，即客户实体。它并不总是需要一个验证器，因为它可能只是用来支持一个用例，而实际上并没有被它修改。

所以我想我可以：

创建 CustomerEdit 类，然后仅在这些类上使用构造函数注入器，而不是在说 CustomerRead 类上，但这会导致类爆炸，而我并不真正希望此应用程序。
拥有一个客户类并在需要时注入验证器。

对于上面的 2 中 IValidatableObject 接口的实现的 Validate 方法似乎是合适的地方。问题是在很多情况下，这个方法是由我自己的代码以外的代码调用的。例如，来自实体框架和某些类型，来自 MVC，因为它们将用作模型类。

所以现在我不得不重写框架代码中的方法，这样我才能进行 DI。这“似乎”不正确，但老实说我不知道为什么。

接下来我看的是 ValidationContext 的 GetService() 方法。

public IEnumerable<ValidationResult> Validate(ValidationContext vc)
{

var customerValidator = (ICustomerValidator)vc.GetService(typeof(ICustomerValidator));
return customerValidator.Validate();

}

但如果我开始这样做，我不是刚刚踏入了ServiceLocator反模式的整个领域，打破了Demeter法则，让测试变得完全痛苦吗？

那么有没有更清洁的方法来解决这个问题，还是只是从我概述的内容中选择我的权衡？

【问题讨论】：