MVC FluentValidation与实体框架在单独的.dll

我有一个单独的.dll与我们的数据库模型和部分类等使用FluentValidation工作正常（这是由桌面条码终端和我们的网站都使用它）。MVC FluentValidation与实体框架在单独的.dll

对于桌面应用程序，我可以读取并显示所有的错误，如下面

public override int SaveChanges() 
    { 
     var errors = this.GetValidationErrors(); 
     if (errors.Any()) 
     { 
      //handle validation errors 
      return 0; 
     } 
     else 
     { 
      return base.SaveChanges(); 
     } 
    }

对于MVC网站，我可以设置在单独的模型验证或创建数据的注释，并得到这些工作的好（这是不是有什么我想要）。我无法理解的事情是如何强制我的模型映射到实体，以便能够在视图中显示流畅的验证消息。我不希望维护两套独立的逻辑，并且条形码应用程序和网站必须使用相同的逻辑。

我是否必须将我的实体直接映射到视图？我一直认为这是一件坏事，不够灵活。或者有什么方法可以说明模型中的字段映射回我的某个实体的属性？也许是一些描述的注释。

编辑：

只是一些澄清的，我需要的类型的验证。

大多数前端输入类型验证仍然保留在viewModels（必需/长度/密码匹配等 - 基本上我可以用于客户端验证的所有东西）。但是，我不想在那里进行所有业务逻辑验证。像电子邮件地址之类的东西必须在设置其他选项之前进行验证，帐户号码必须是基于名称的特定格式（我不能用正则表达式做的事情）。这个特定的日期不是有效的交货日期等。

我想我可以做的一件事就是将这些添加到ValidationSummary中，并将它们与各个字段分开显示。

来源

2013-04-04 Peter Lea

只是一个更新。为了得到我需要的两层验证，我必须将所有实体模型类标记为IValidatable。然后我重写每个类的验证方法，并在那里调用我的流畅验证验证器方法，传回所需的错误。对于modelstate.addmodelerror我将该键设置为字段名称，并将其映射回来没问题。多一点的代码，但它的作品。如果我找到一个更好的方法来做这个病态的更新。

来源

2013-04-08 17:00:33

我想你只是在看错的情况。 MVC的全部内容是关注的分离。数据库需要知道的事情是你的观点可能不太在意，反之亦然。这就是为什么推荐的做法是将视图模型与视图一起使用，而不是实体本身。

验证是相同的。类似于密码确认需要与用户输入的密码相匹配的事实根本不涉及数据库。或者更恰当地说，像密码中最小字符数量的验证与数据库无关;它只会收到密码的腌制和散列版本。因此，将这种验证放在您的实体上将是错误的。它属于视图模型。

当我第一次开始使用MVC时，我曾经将所有验证逻辑添加到我的实体类中，然后在我的视图模型上重复同样的验证。随着时间的推移，我开始意识到实际上需要的验证非常少。事实上，绝大多数的验证应该只是放在你的视图模型上。它充当各种看门人的角色;如果数据足够满足您的视图模型，那么您的数据库就足够好了。在您的实体上有意义的验证类型是Required之类的东西，但即使如此，只有在必须到达数据库时具有值的可空字段上才是必需的。像DateTimes这样的事情默认情况下是不可空的，而且EF足够聪明，使它们在默认创建的表上不可空。 MaxLength有时是值得的，如果应该对数据库中的文本字段的长度有一个严格的限制，但通常情况下，nvarchars工作得很好。

反正问题是，如果你真的坐下来开始评估你的实体验证，你可能会看到，大部分是只适用于应用程序如何工作和不怎样的商业逻辑数据在数据库级别表示。这是关键的要点：在您的实体上，您只需要数据库所需的验证。这通常很薄。

来源

2013-04-04 19:14:40

嗨克里斯和谢谢，我更新了我的问题，以解释我需要更好的类型。不幸的是，即使最简单的更新可以发生，我们也确实需要满足一大堆标准，并且由于两个单独的程序必须使用它，所以我真的需要它。 – 2013-04-04 19:58:09

您的视图模型也可以共享。只需将它们添加到您的类库中即可。我唯一的观点是，你应该从验证的角度来看待你的视图模型。从实体的角度来看，您唯一需要担心的是完美的数据库完整性问题。 – 2013-04-04 20:58:07

MVC FluentValidation与实体框架在单独的.dll

回答

相关问题