IValidatableObject 和依赖注入支持答案

【问题标题】：IValidatableObject and Dependency Injection supportIValidatableObject 和依赖注入支持
【发布时间】：2011-11-10 16:04:02
【问题描述】：

在我的 ASP.NET MVC 3 项目中，我在一个单独的类库项目中实现了存储库模式。

我也使用 EF 作为 ORM。我还使用IValidatableObejct 接口实现了一些模型验证。这是它的样子：

[MetadataType(typeof(AccommPropertySeasonPeriodAlias.MetaData))]
public partial class AccommPropertySeasonPeriodAlias : IValidatableObject {

    private class MetaData {

        [StringLength(5), Required]
        [Display(Name = "Period Alias Name")]
        public string AccommPropertySeasonPeriodAlias1 { get; set; }
    }

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext) {

        var repo = new AccommPropertySeasonPeriodAliasRepository();

        if (repo.GetAll(this.AccommPropertySeasonID).
            Where(x => x.AccommPropertySeasonPeriodAlias1 == this.AccommPropertySeasonPeriodAlias1) != null)

            yield return new ValidationResult("Alias Name needs to be unique");
    }
}

如您所见，从现在开始，我的模型完全紧耦合，因为我直接使用了AccommPropertySeasonPeriodAliasRepository 类而不是使用IAccommPropertySeasonPeriodAliasRepository。

正确的做法是什么，以便我的模型可以，嗯，（不确定这是否是正确的词）fake-able 用于单元测试?

【问题讨论】：

标签： c# asp.net asp.net-mvc asp.net-mvc-3 dependency-injection

【解决方案1】：

可以使用 MVC 的内置解析器注入验证逻辑。

查看使用 MVC 中注册的容器解析的 ModelValidatorProvider 的用法。

ASP.NET MVC 3: Validating model when information external to the model is required

【讨论】：

完全是我想要的。非常感谢！

【解决方案2】：

唯一性约束超出了该实体的范围。从外部添加新实体时，您应该验证此约束。此验证不应该属于实体本身。这取决于实体所在的上下文，而不仅仅是该实体。

【讨论】：

那么，你说没有办法在这个作用域内注入repository？
我还在使用唯一约束验证我的数据库中值的唯一性，我的应用无法将相同的数据插入到我的数据库中，但我的目的是为用户提供良好的反馈出了什么问题。
我猜你可以使用属性注入（social.msdn.microsoft.com/Forums/en-CA/adodotnetentityframework/…）。但这是错误的做法，您的实体根本不应该依赖存储库。

【解决方案3】：

您可以在ValidationContext 上使用GetService(Type serviceType) 方法 - 请参阅此处：https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.dataannotations.validationcontext.getservice?view=net-5.0#System_ComponentModel_DataAnnotations_ValidationContext_GetService_System_Type_

这是一种服务定位器模式，但比使用DataAnnotationsModelValidator 的一些更复杂的实现要简单得多。有时，一个简单的解决方案（使用 ServiceLocator 模式）的缺点超过了一个复杂的 IMO 的成本。

【讨论】：