在 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; }
}

所以我的问题是，这种差异何时真正重要？

我的想法是，接口往往更“可重用”，并且为单个类制作一个接口没有多大意义。您还可以争辩说，您可以以允许您在多个对象上使用接口的方式设计您的类和接口，但我觉得这是试图将您的模型适应其他东西，而它们实际上应该独立存在。你怎么认为？

我喜欢你的接口方法，因为它允许你为你的模型定义一个契约，你可以使用它来适应你的 ORM 生成的类。这将使您能够将应用程序与 ORM 框架分离，并更多地利用 MetadataType 接口，因为它充当数据验证元数据以及模型的契约。您还可以使用序列化属性来装饰您的界面，以便在 WCF 中使用，从而从界面中获得更多用途。我关注了一些建议创建元数据类的早期博客，但我再次认为接口解决方案是一个好主意。