Entity Framework 5 代码优先配置封装答案

【问题标题】：Entity Framework 5 code-first configuration encapsulationEntity Framework 5 代码优先配置封装
【发布时间】：2012-11-25 21:17:30
【问题描述】：

我想知道（而且我讨厌使用“最佳实践”这个词） - 但这是一种处理配置的好方法，因为它封装了 AAA 的配置？

我看到很多示例，其中OnModelCreating 是用于创建数据库的大量指令列表，而冗长的方法告诉我某些事情并不安静。

public class MyContext : DbContext
{
    public MyContext() : base("name=MyDb") { }

    public DbSet<AAA> AAAs { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
        modelBuilder.Configurations.Add(new AAA.Configuration());
    }
}

还有一个可以配置的类

public class AAA
{
    [Key] 
    public int Id { get; set; }

    [Required] 
    public string Details { get; set; }

    internal class Configuration : EntityTypeConfiguration<AAA>
    {
        public Configuration()
        {
            // Set all the funky stuff here
        }
    }
}

我知道可能没有正确的方法。在我投入大量时间和眼泪之前，我正在寻找一个原因，为什么这可能是世界上最糟糕的想法，或者是否有办法做类似的事情？

编辑

一位同事建议将此作为使用静态属性的替代方法

public class AAA
{
    [Key] 
    public int Id { get; set; }

    [Required] 
    public string Details { get; set; }

    public static EntityTypeConfiguration<AAA> Configuration
    {
        get { return new AAAConfiguration(); }
    }

}

internal class AAAConfiguration : EntityTypeConfiguration<AAA>
{
   public AAAConfiguration()
   {
            // Set all the funky stuff here
   }
}

我喜欢这个，因为它在配置实例化方面给了我更多的灵活性。

【问题讨论】：

标签： c# ef-code-first entity-framework-5

【解决方案1】：

这取决于。到目前为止，我可以说我不关心数据库的生成。它很好并且具有我不关心的优点（独立于平台）。它限制了完全使用 SQL Server - 所以它回到了数据库项目。

这是一个妥协的世界，而且 - 抱歉 - 最佳实践伴随着大量的限制。

【讨论】：

是的，我真的认为 Dapper 或类似的 DAL 是更好的选择。对于所有的菜鸟魔法，当您想要处理大量数据并且您总是受到约定的限制时，它似乎又慢又笨重。
不确定。到目前为止，我使用 BlToolkit 的速度非常快——在一个处理数百毫米行的项目中，我正在使用 96 核 SSD 支持的 ExaData 服务器和一个 24 核英特尔服务器——但现在我正在转向 EntityFramework 进行交易项目.那说：我不在那里进行数据库维护，因为我在数据库中还有存储过程、视图、多个文件组和其他代码首先不知道的特性。 EF 中的代码优先仍然非常有限。
是的，我真的不想使用它。它是强加给我的。现在我必须学会足够的知识，以便下次能够说不，尽管我必须承认它对于快速发展一个想法非常有好处。当想法变成现实时，麻烦它不是很可持续。
这真的取决于。对于大多数情况，“在表、关系和索引中定义字段”可能就足够了。当您还需要视图、设置存储过程、触发器、使用调整（文件组）或开始使用企业功能（表分区）时，情况会有所不同。
@Peter 它可以是相当可持续的（尤其是代码优先迁移——让你的源代码控制你的整个数据库历史，这太棒了）——比维护大量的 SQL 脚本恕我直言要容易得多。 -- 还有很多人们抱怨的其他东西（即视图等）都在他们的功能路线图上......所以它来了。

【解决方案2】：

我个人认为您采用的方法没有问题。我最近刚刚解决了一个类似的难题，唯一的区别是我的数据层中有EntityTypeConfiguration<T> 类，而不是我的模型中。我也在做这些映射类中的所有映射逻辑；这意味着我不必使用 EF 特定属性来装饰我的模型，让它们完全不知道持久性。

使用您的方法，在OnModelCreating 方法中，您只需要为每个要保留的类设置一行，此外，如果您不清除 EF 创建的缓存，则此代码只会被命中一次，所以它只是一种一次性的引导程序，因此长方法不是问题吗？

我认为你的方法很好，但我相信在这个问题上会有一些不同的看法。

【讨论】：