c# - 如何使用 DI 通过 IValidatableObject 接口(interface)向实体提供验证器？

Question

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

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

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

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

我想我会调用类型工厂中的 Unity 并从那里注入(inject)。

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

所以我想我可以:

1. 制作 CustomerEdit 类，然后仅在这些类上使用构造函数注入(inject)器，而不是在说 CustomerRead 类上，但这会导致类爆炸，我真的不希望这个应用程序出现这种情况。
2. 只有一个客户类并在需要时注入(inject)验证器。

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

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

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

public IEnumerable<ValidationResult> Validate(ValidationContext vc)
{

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

}

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

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

Answer 1

最重要的原则:KISS .

因此，除非您要创建 10000 个业务对象，否则请不要费心，始终注入(inject)您的验证服务。

如果这样做会降低性能，请根据需要将类拆分为读取/编辑模型。