在 MVC 中使用数据注释时，使用接口与 MetadataType 的优点和缺点
如果您阅读这篇关于验证的文章数据注释验证器，它表明您可以使用 MetadataType 属性向部分类的属性添加验证属性。您可以在使用 LINQ to SQL、Entity Framework 或 Subsonic 等 ORM 时使用它。然后您可以使用“automagic”客户端和服务器端验证。它与 MVC 配合得非常好。
然而，我的一位同事使用一个接口来完成完全相同的结果。它看起来几乎完全相同，并且在功能上完成相同的事情。因此，他没有这样做：
[MetadataType(typeof(MovieMetaData))]
public partial class Movie
{
}
public class MovieMetaData
{
[Required]
public object Title { get; set; }
[Required]
[StringLength(5)]
public object Director { get; set; }
[DisplayName("Date Released")]
[Required]
public object DateReleased { get; set; }
}
他这样做了：
public partial class Movie :IMovie
{
}
public interface IMovie
{
[Required]
object Title { get; set; }
[Required]
[StringLength(5)]
object Director { get; set; }
[DisplayName("Date Released")]
[Required]
object DateReleased { get; set; }
}
所以我的问题是，这种差异何时真正重要？
我的想法是，界面往往更“可重用”，并且只需要一个界面就可以实现一个界面。类没有多大意义。您还可以争辩说，您可以以允许您在多个对象上使用接口的方式设计您的类和接口，但我觉得这是试图将您的模型适应其他东西，而它们实际上应该独立存在。你怎么认为？
If you read this article on Validation with the Data Annotation Validators, it shows that you can use the MetadataType attribute to add validation attributes to properties on partial classes. You use this when working with ORMs like LINQ to SQL, Entity Framework, or Subsonic. Then you can use the "automagic" client and server side validation. It plays very nicely with MVC.
However, a colleague of mine used an interface to accomplish exactly the same result. it looks almost exactly the same, and functionally accomplishes the same thing. So instead of doing this:
[MetadataType(typeof(MovieMetaData))]
public partial class Movie
{
}
public class MovieMetaData
{
[Required]
public object Title { get; set; }
[Required]
[StringLength(5)]
public object Director { get; set; }
[DisplayName("Date Released")]
[Required]
public object DateReleased { get; set; }
}
He did this:
public partial class Movie :IMovie
{
}
public interface IMovie
{
[Required]
object Title { get; set; }
[Required]
[StringLength(5)]
object Director { get; set; }
[DisplayName("Date Released")]
[Required]
object DateReleased { get; set; }
}
So my question is, when does this difference actually matter?
My thoughts are that interfaces tend to be more "reusable", and that making one for just a single class doesn't make that much sense. You could also argue that you could design your classes and interfaces in a way that allows you to use interfaces on multiple objects, but I feel like that is trying to fit your models into something else, when they should really stand on their own. What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我喜欢你的接口方法，因为它允许你为你的模型定义一个契约，你可以使用它来适应你的 ORM 生成的类。这将使您能够将应用程序与 ORM 框架解耦，并更多地利用 MetadataType 接口，因为它充当数据验证元数据以及模型的契约。您还可以使用序列化属性来装饰您的界面，以便在 WCF 中使用，从而从界面中获得更多用途。我关注了一些建议创建元数据类的早期博客，但我再次认为接口解决方案是一个好主意。
I like your interface approach as it allows you to define a contract for your model which you can use to adapt your ORM generated classes to. That would allow you to decouple your app from the ORM framework and get more use out of the MetadataType interface as it serves as data validation metadata as well as a contract for your model. You could also decorate your interface with serialization attributes for use in WCF gaining more use out of the interface. I followed a few early blogs that recommended creating a metadata class but again I think the interface solution is a nice idea.
如果这两个选项是我面临的两个选项，我个人可能会选择界面方式，只是因为我认为它看起来更干净。但这完全取决于个人品味 - 我对 .NET 的内部工作原理了解不够，无法确定，但我不知道这两种方法的实际功能会有所不同。
另一方面，更好的方法是使用数据传输对象 (DTO) 来回发送数据，并对它们提出验证要求。也就是说，您不需要
Movie对象满足所有验证要求，而是要求MovieInput对象满足所有这些要求，然后创建代码来映射正确的 <将 code>MovieInput 转换为Movie。 （如果您不想手动执行此操作，可以使用 AutoMapper 或其他实用程序）。这个概念基本上是在 in 的方式上以及 out 的方式上拥有类似视图模型对象的东西 - 我也可以让
MovieInput被称为MovieViewModel并使用它来将数据传入和传出服务器。If those two options are the two I am presented with, I would personally probably choose the interface way, simply because I think it looks cleaner. But this is entirely based on personal taste - I don't know enough about the inner workings of .NET to say for sure, but I don't know any case where the actual functionality of the two approaches would differ.
On the other hand, a much better approach would be to use Data Transfer Objects (DTO's) for sending data back and forth, and have the validation requirements on them. That is, instead of requiring that the
Movieobject meet all the validation requirements, you require that aMovieInputobject meets all those requirements, and then create code to map a correctMovieInputinto aMovie. (If you don't want to do that manually, you could use AutoMapper or some other utility).The concept is basically to have something like a View Model object on the way in just as well as on the way out - I could just as well have let
MovieInputbe calledMovieViewModeland use it for transferring of data both in and out of the server.我认为这两种方法之间没有功能差异。我不确定可重用性在这里是否真的很重要，因为验证通常是在“一次性”ViewModel 上进行的，而这些视图模型可能不会得到太多（如果有的话）重用。
I see no functional difference between the two approaches. I'm not sure reusability is really important here, given that validation will most often be on "one-off" ViewModels that probably won't get much, if any, reuse.