数据注释真的是验证的好主意吗？
随着我对 ASP.NET MVC 的了解越来越多，我对数据注释的了解也越来越多。
特别是在 MVC 中，它们用于验证，这给了我一些担忧。
最大的原因是我喜欢将我的模型保持为 POCO 并尽可能干净。
现在，如果我在解决方案中的多个项目（即 Web 前端、桌面应用程序、Web 服务）中共享这些模型类会怎样？
基本上，我担心特定于我的 MVC 前端应用程序的注释可能会影响其他一些项目，例如动态数据等。 我已经将业务对象与数据库模型（在本例中为 LINQ2SQL）分离，因此我不担心注释会影响我的 DAL，但我想知道我对其他项目的担心是否合理。
另外，我认为将所需的错误消息与您的模型联系起来有点疯狂。
我想如果我为每个项目（Web、桌面、Web 服务等）创建单独的模型，问题就会得到解决，但这实际上是我当前共享模型的直接副本。 这是正确的道路吗？
这将对我的解决方案产生重大影响（从一个模型到另一种模型的映射）。
你觉得怎么样？
我想听听您认为数据注释的好用和坏用。
As I'm learning more and more about ASP.NET MVC the more I am introduced to Data Annotations.
Specifically in MVC they are used for validation and this gives me some concerns.
The biggest is due to the fact that I like to keep my model as POCOs and as clean as possible.
Now what if I have those model classes shared across multiple projects in a solution (i.e. web front end, desktop app, web services)?
Basically I am concerned that annotations specific for my MVC front end app could influence some other projects like Dynamic Data, etc.
I already have my Business Objects separated from my database model (in this case LINQ2SQL) so I don't worry about annotations having influence on my DAL, but I'm wondering if my fear about other projects is legitimate.
Also I think that tying a required error message to your model is a bit insane.
I suppose the problem would be solved if I created separate models for each project (web, desktop, web service, etc.) but this would be practically a direct copy of my currently shared model.
Is it the right path?
It would have big impact on my solution (much mapping from one model to another happening).
What do you think?
I would like to hear what you consider good and bad use of Data Annotations.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我发现数据注释对于规则永远不会根据上下文（例如电子邮件地址）而改变的模型很方便。
但对于更复杂的验证（多个字段，需要数据库访问等），我使用 使用访问者和扩展方法进行实体验证。
I find Data Annotations convenient for models where the rules never change depending on context such as an email address.
But for more complex validation (multiple fields, requires DB access, etc.) I use the visitor pattern described in Entity validation with visitors and extension methods.
真的，真的很好的问题。特别是因为所有闪亮的演示示例应用程序都是围绕处理所有验证的 DataAnnotations 构建的，因为它是一个如此漂亮、闪亮的卖点。无论如何，谁喜欢进行验证呢？
我认为更好的看待这个问题的方法是，它们应该成为更全面的验证解决方案的一部分，无论是出于您提到的结构原因还是它们的局限性——您如何验证诸如“此用户名是否唯一？”之类的内容。或“该经理是否可以将此任务分配给该员工？”使用数据注释？
Really, really good question. Especially since all the shiny demo example apps are built around DataAnnotations handling all the validation because its such a nice, shiny selling point. And who likes doing validation anyhow?
I think the better way to look at this is that they should be part of a fuller validation solution, both for the structural reasons you mention as well as their limitations -- how do you validate stuff like "Is this user name unique?" or "Is this manager allowed to assign this task to this employee?" using data annotations?
DataAnnotations 不是唯一可用于验证的方法，您可以使用多种验证方法。我在使用 DataAnnotations 时看到的大多数验证都是专门用于验证将进入数据库的数据。如MaxLength()和Range()。
在编写您自己的验证时，IValidatableObject 是我所见过的最灵活的。但是，它对您拥有一个可以保存所有对象的单个存储库的具体示例没有帮助。但没有恐惧！
IDataErrorInfo 是验证数据的另一种方法，该方法可以单独在您的 MVC 应用程序中使用，并且不会影响其他项目。
如果类实现了 IDataErrorInfo 接口，则 ASP.NET MVC 框架将在创建该类的实例时使用此接口。因此，您可以使用服务定位器接口或类似的东西来分离验证。
然而，我发现 IValidatableObject 是一个更好的实现。
DataAnnotations isn't the only method available for validation and you can use more than one validation method. Most validations I've seen when using DataAnnotations are specifically for validating the data that will go in the database. Such as MaxLength() and Range().
IValidatableObject is the most flexible that I've seen when it comes to writing your own validations. However, it doesn't help your specific example of having a single repository that would hold all your objects. But no fear!
IDataErrorInfo is another way you can validate data and this one can be used in your MVC app alone and it wouldn't affect other projects.
If a class implements the IDataErrorInfo interface, the ASP.NET MVC framework will use this interface when creating an instance of the class. Thus you can separate your validation using a service locator interface or something similar.
I find IValidatableObject to be a better implementation, however.
我个人认为 DataAnnotations 对于验证 MVC ViewModel 和发布的输入非常有用。我永远不会把它们纳入我的商业模式。
我也非常偏爱基于属性的验证属性，因为它很容易进入反射来发现哪些属性在哪里。
I personally find DataAnnotations very nice for the validation of MVC ViewModels and posted input. I would never ever ever ever put them on my business models.
I've also become quite partial to attribute based validation attributes because its really easy to get into Reflection to discover what attributes are where.
不确定 DataAnnotations 是否会扰乱您的其他项目，但预计它们会忽略 DataAnnotations，除非您创建一些类来检查它们。
为了使 POCO 尽可能简单，DataAnnotations 的目的是将元数据和数据保存在同一位置（即，如果要求 _UnitsInStock 必须始终为正整数，则此要求与“库存单位”的数据定义有关） “并且完全符合模型的定义）。它还有助于避免一些错误，因为无论您在何处使用验证（在 mvc 项目内），规则总是相同的（因此您在检查时不能忘记检查页面 A 中变量的最小值）它在B页）。错误消息不是必需的，但您可以使用它来显示更友好的消息，并且此错误消息将随处显示。
它还使得实现自动化服务器和客户端验证（MVC）变得非常容易。
另一方面，尽管您有能力创建自定义属性来检查业务规则，但它比使用“业务类”需要更多的知识和耐心（如果您不习惯的话），据我所知，它是仅由 mvc 2 官方支持。
如果您的模型类在其他项目之间共享，则可能您还有一个共享验证层，因此请改用此验证层。如果您没有它，那么 DataAnnotations 将使您在 MVC 项目上的生活更轻松。
Not sure if DataAnnotations will mess up your other projects, but it's expected them will ignore DataAnotations unless you create some classes to check them.
About keeping your POCO as simple as possible, DataAnnotations' intention is to keep metadata and data at the same place (i.e. if it's required that _UnitsInStock must always be a positive integer, somehow this requirement is related to the data definition of "units in stock" and fits perfectly the definition of model). It also helps avoiding some mistakes, since that no matters where you are using validation (inside a mvc project) the rules will always be the same (so you can't forget to check a variable for a minimum value in page A while you check it in page B). The error messages are not required, but you can use it to show a more friendly message, and this error message will be shown everywhere.
It also makes very easy to implement automated server and client validation (mvc).
In other hand, despite you have the ability to create custom attributes to check business rules, it requires more knowledge and patience than using a "business class" (if you're not used to it), and as far as i know, it's only officially supported by mvc 2.
If your model classes are shared among other projects, probably you also have a shared validation layer, so use this validation layer instead. If you don't have it, so DataAnnotations will make your life easier on MVC projects.
我认为您不需要担心在多种技术中共享装饰域。 DataAnnotations 是 BCL 的一部分，您可以在 WCF、WPF、MVC、Web 窗体中使用它，凡是您能想到的（甚至可能在 Silverlight 中）。
由于 DataAnnotations 现在是 BCL 的核心部分，我们可以预期其他验证框架将来能够读取这些属性，正如 Enterprise Library Validation Application Block 5.0 已经做到的那样。这允许稍后使用更复杂的验证来扩展模型，而无需更改核心验证规则。
但是，我可以理解您希望将模型和验证规则分开。如果这是您想要的，验证应用程序块 (VAB) 可能是一个很好的替代方案（甚至是补充，因为它与 DataAnnotations 集成）。 VAB 支持基于配置的验证，这允许您将验证规则与模型完全分离。
然而，当您的验证规则非常简单时，VAB 可能就有点大材小用了。它非常强大且可扩展，但学习起来也很复杂且耗时。
I don't think you need to worry about sharing a decorated domain in multiple technologies. DataAnnotations is part of the BCL and you can use it in WCF, WPF, MVC, Web Forms, you name it (perhaps even in Silverlight).
Because DataAnnotations is now a core part of the BCL we can expect other validation frameworks to be able to read those attributes in the future, as Enterprise Library Validation Application Block 5.0 already does. This allows extending the model with more complex validations later on, without having you change the core validation rules.
However, I can understand you want to keep your model and the validation rules separate. If this is what you want, Validation Application Block (VAB) can be a good alternative (or even addition, because of its integration with DataAnnotations). VAB supports configuration-based validation, which allows you to completely separate the validation rules from the model.
When your validation rules are very simple however, VAB can be an overkill. It is extremely powerful and extendable, but it is also complex and time consuming to learn.
您的问题之一似乎是您想保持代码干净。
这是 Asp.net MVC 出色实现的目标。
您应该关注的是使用视图模型，它有助于将业务逻辑与演示文稿分开。
这是一篇旧文章，但它解释了基础知识：
http://geekswithblogs.net /michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx
One Of your Problems Seems to be that you want to keep your code Clean.
This Is something Asp.net MVC achieves Wonderfully.
What you should Look at is using View models wich helps to separate your business logic from your Presentation.
This Is an old article But It explains the basics :
http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx