我需要映射文件吗？

问题描述：

使用实体框架6，我想知道如果我需要一个映射文件。我有这样定义的模型：我需要映射文件吗？

[Table("UploadedFile")] 
public partial class UploadedFile 
{ 
    [Key, ForeignKey("Resource"), DatabaseGenerated(DatabaseGeneratedOption.None)] 
    public System.Guid FileId { get; set; } 
    public virtual Resource Resource { get; set; } 

    //... 
    public System.DateTime Modified { get; set; } 

    public bool IsActive { get; set; } 
    public byte[] RecordVersion { get; set; } 

    public UploadedFile() 
    { 
     Resource = new Resource(); 
    } 
}

我的映射文件是这样的：

public class UploadedFileMapping : EntityTypeConfiguration<UploadedFile> 
{ 
    public UploadedFileMapping() 
    { 
     //Primary key 
     HasKey(t => t.FileId); 
     //Constraints 
     Property(t => t.RecordVersion).IsRowVersion(); 
    } 
}

我可以只依靠模型中的属性？使用映射文件有什么优点/缺点？

我相信模型中的[Key]属性否定了HasKey的需要，这是正确的吗？

答

您可以使用基于属性的映射。您的情况下不需要映射文件。但我建议学习Fluent Api并使用它。

一般来说，你有多种选择：

不要使用任何明确的映射 - 仅仅依靠公约（内置或自定义）。它可以用在简单的情况下。为此，您的DbContext应该通过DbSet或通过已知类型的引用来了解您的实体。

优点：
- 无需额外的代码。
缺点：
- 你必须知道的所有公约和该解决方案是不灵活。

使用数据注解。基于属性的映射非常直观和简单。

优点：
很简单。
它不仅可以被实体框架使用，也可以用于验证（例如在ASP.NET MVC或WPF中）。
某些属性只能通过数据注释（例如MinValue和DefaultValue）来定义。
缺点：
- 它不像Fluent API那么灵活。
- 由于大量的属性，读取模型代码可能有点困难。
- 您的模型与实体框架紧密结合。

用流利的API（有映射文件）。这是具有更多可能性的最先进的方案（请参阅here以获得更详细的参考资料）。

优点：
- 它灵活。您可以有更多的映射可能性。
- 您可以拥有干净的域模型，而不需要实体框架依赖。
缺点：
- 它可以是一个有点困难。

，你也可以结合以前的3种方法。您可以一起使用所有这些解决方案。例如：

您满意的默认的命名惯例，这样你就不必为您的表定义名称。
您可以使用数据注释重新使用它们进行验证。
您可以使用Fluent Api定义不支持的数据注释部分。
- 缺点：
- 这是一个有点复杂，找出整个配置，因为它在多个地方定义。所以请谨慎使用此方法。

答

EF Fluent Api比数据注释更好，因为它允许域模型层隔离并且更灵活（例如，IsRowVersion只能在流畅的Api中添加）。关键属性是多余的。

但是，它更多的是一种痛苦。我不会完全同意域模型隔离......它取决于您在应用程序中使用DTO/ViewModels/Models的方式。此外，您应该只真正从数据库中投射出您真正想要的东西，因此应该永远不会有整个数据库以代码模型化的时间。（这仅用于创建表和迁移） –

我需要映射文件吗？

相关推荐