数据注释真的是验证的好主意吗？

Question

随着我对ASP.NET MVC的了解越来越多，我对数据注释的介绍越多 特别是在MVC中，它们用于验证，这给了我一些顾虑 最大的原因是我喜欢将我的模型保持为POCO并尽可能保持清洁 现在，如果我在解决方案中的多个项目中共享这些模型类（即Web前端，桌面应用程序，Web服务），该怎么办？ 基本上我担心我的MVC前端应用程序特有的注释会影响动态数据等其他项目。 我已经将我的Business Objects与我的数据库模型（在本例中为LINQ2SQL）分开，所以我不担心注释对我的DAL有影响，但我想知道我对其他项目的恐惧是否合法。

此外，我认为将所需的错误消息绑定到您的模型有点疯狂。

如果我为每个项目（Web，桌面，Web服务等）创建单独的模型，我想问题就会解决，但这实际上是我当前共享模型的直接副本。 这是正确的道路吗？ 这将对我的解决方案产生重大影响（从一个模型到另一个模型的映射很多）。

你怎么看？ 我想听听你认为数据注释的好坏使用。

Answer 1

我发现数据注释对于规则永远不会改变的模型很方便，具体取决于电子邮件地址等上下文。

但是对于更复杂的验证（多个字段，需要数据库访问等），我使用Entity validation with visitors and extension methods中描述的访问者模式。

Answer 2

DataAnnotations不是唯一可用于验证的方法，您可以使用多种验证方法。我在使用DataAnnotations时看到的大多数验证都专门用于验证数据库中的数据。例如MaxLength（）和Range（）。

IValidatableObject是我在编写自己的验证时看到的最灵活的。但是，它没有帮助您使用单个存储库来保存所有对象的具体示例。但没有恐惧！

IDataErrorInfo是另一种验证数据的方法，这个方法可以单独用于你的MVC应用程序，不会影响其他项目。

如果类实现了IDataErrorInfo接口，则ASP.NET MVC框架将在创建类的实例时使用此接口。因此，您可以使用服务定位器界面或类似的东西来区分您的验证。

然而，我发现IValidatableObject是一个更好的实现。

Answer 3

真的，非常好的问题。特别是因为所有闪亮的演示示例应用程序都围绕DataAnnotations构建，处理所有验证，因为它是一个非常好的，闪亮的卖点。无论如何谁喜欢做验证？

我认为更好的方法是，它们应该成为更全面的验证解决方案的一部分，无论是出于您提及的结构原因还是它们的局限性 - 您如何验证诸如“此用户名是否唯一”之类的内容？”或者“该经理是否允许将此任务分配给该员工？”使用数据注释？

Answer 4

我个人认为DataAnnotations非常适合MVC ViewModels的验证和发布的输入。我永远不会把它们放在我的商业模式上。

我也非常偏爱基于属性的验证属性，因为它很容易进入Reflection以发现哪些属性在哪里。

Answer 5

不确定DataAnnotations是否会弄乱你的其他项目，但是除非你创建一些类来检查它们，否则它们会被忽略DataAnotations。

关于保持POCO尽可能简单，DataAnnotations的目的是将元数据和数据保存在同一个地方（即，如果要求_UnitsInStock必须始终为正整数，则该要求与数据定义有关“库存单位“完全符合模型的定义”。它还有助于避免一些错误，因为无论你在哪里使用验证（在mvc项目中），规则总是相同的（所以当你检查时，你不能忘记在A页中检查变量的最小值）它在页面B）。错误消息不是必需的，但您可以使用它来显示更友好的消息，并且此错误消息将随处显示。

它还可以非常轻松地实现自动服务器和客户端验证（mvc）。

另一方面，尽管您有能力创建自定义属性来检查业务规则，但它需要比使用“业务类”（如果您不习惯）更多的知识和耐心，并且就我而言知道，它只有mvc 2正式支持。

如果您的模型类在其他项目中共享，那么您可能还有一个共享验证层，因此请使用此验证层。如果您没有它，那么DataAnnotations将使您在MVC项目上的生活更轻松。

Answer 6

我认为您不必担心在多种技术中共享装饰域。 DataAnnotations是BCL的一部分，您可以在WCF，WPF，MVC，Web窗体中使用它，您可以命名它（甚至可能在Silverlight中）。

由于DataAnnotations现在是BCL的核心部分，因此我们可以期望其他验证框架能够在将来读取这些属性，正如Enterprise Library Validation Application Block 5.0所做的那样。这允许稍后使用更复杂的验证扩展模型，而无需更改核心验证规则。

但是，我可以理解您希望将模型和验证规则分开。如果这是您想要的，验证应用程序块（VAB）可以是一个很好的选择（甚至是添加，因为它与DataAnnotations集成）。 VAB支持基于配置的验证，允许您将验证规则与模型完全分开。

但是，当您的验证规则非常简单时，VAB可能会过度。它功能强大且可扩展，但学习起来也很复杂且耗时。

Answer 7

您的一个问题似乎是您希望保持代码清洁。 这是Asp.net MVC实现的奇妙之处。

您应该看到的是使用View模型，这有助于将您的业务逻辑与您的演示文稿分开。

这是一篇旧文章但它解释了基础知识： http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx