企业中企业实体验证的首选方法

Question

让我先说这个问题，并说明使用实体框架不适合我们。

在我们的财务组织中，我们有跨越解决方案的业务实体。有些人拥有其他人不需要的界面。验证和业务规则必须包含在实体中。

我针对为我生成的DAL和DTO编写代码，这些DAL使用procs在数据库上运行CRUD（可能是SQL可能是Oracle）。

因此，当我创建MVC，WCF，控制台应用程序等。如果可以实现更好的验证方法，问题一直在唠叨。

这里是一个实体对象一个典型的几个特性：

[DefaultValue("")] 
public string Branch { 
    get { return _branch; } 
    set { 
     if (value != null && value == _branch) return; 
     const string propertyName = "Branch"; 
     ValidationInstance.Clear(propertyName); 
     ValidationInstance.ValidateRequired(propertyName, value); 
     ValidationInstance.ValidateNumeric(propertyName, value); 
     ValidationInstance.ValidateLength(propertyName, value, 2); 
     _branch = value; 
     if (EntityState != EntityStateType.New) 
      EntityState = EntityStateType.Changed; 
    } 
} 

    [DefaultValue(0)] 
public decimal HighDefermentMargin { 
    get { return _highDefermentMargin; } 
    set { 
     if (value == _highDefermentMargin) return; 
     const string propertyName = "HighDefermentMargin"; 
     ValidationInstance.Clear(propertyName); 
     ValidationInstance.ValidateRange(propertyName, value); 
     _highDefermentMargin = value; 
     if (EntityState != EntityStateType.New) 
      EntityState = EntityStateType.Changed; 
    } 
} 

正如你可以看到有进行越来越详细的验证数据注释和显式调用验证类的组合。

在一个MVC应用程序中，我们在ViewModel上苦心地复制了验证，因此我们获得了客户端和服务器端的验证。这里是同一属性的视图模型版本从上面：

[Required] 
[Range(0.0, 99.99)] 
[Display(Name = "High Deferment Margin")] 
public decimal HighDefermentMargin { get; set; } 

这里的主要区别是，在实体验证加载错误插入的验证类的错误集合，可以在当时的实体进行查询去拯救自己。如果（！IsValid）则抛出一个包含错误数组的自定义异常。控制器通过它们循环并将它们添加到ModelState中。

我开始研究一些几乎有几百个字段的类。即使它们被面向对象分解，领域的数量仍然非常高。这些都是贷款认证等，对于单个记录有很多数据。必须写出对许多属性的验证使我想吐。我不能只编写一个实用程序来生成实体和验证，因为业务规则是驱动验证的原因，而不是数据库。这意味着一个字段在数据库中可以为空，但不允许根据业务规则保留为空值，或者该字段可以为空，但只有在单独的字段具有值时才是空的等。

所以，可以使用just View Model中的数据注释与实体的实现方式是否相同？我可以为非标准验证编写自定义验证器，然后为更复杂的内容编写业务规则。验证错误是否会从实体中获得更高的级别，以便UI可以像ModelState一样以友好的方式通知用户？其他人在这种情况下做什么？

Answer 1

通常，属性上的验证属性可以获得不同的验证结果（验证是否通过），具体取决于它是在UI层，BUsiness层还是DAL中评估的。考虑一个Required属性，如果应用于ViewModel，它可能会失败，但在业务层中，它可以通过，因为用户没有提供的值是从其他源提供的。然而，像电子邮件格式这样的验证规则总是会得到相同的结果。但是，存在一些可能需要在业务层重复验证的成熟问题......仅仅是因为Web服务器更容易受到攻击并且更容易受到攻击。但是，重复两次相同的验证并不意味着要写两次代码。您可以收集您想要应用于同一概念实体的各种版本（ViewModel，BL，DAL）的常用dll中的多个图层中应用的所有属性，其中您定义了MetaDataType。这样，您可以在不重复代码的情况下满足安全要求。

至于建议的saravanan你可以使用异常通信在其它层UI层发现的验证错误（还可以配置WCF通信异常细节给客户端）