EF代码首先是模块化设计

Question

首先使用ef4代码，您可以创建和编译类和dbcontext。如果要在模型集的已编译dll中添加一些类/表和关系，会发生什么？

到目前为止，我提出的解决方案是使用“部分”类，这些类将在后面得到称赞，第二个是编写一个全新的dbcontext，包括第一个以某种方式或扩展它，但是这个将意味着每个模块的额外数据库连接（每个db上下文）。有关于此的任何想法？什么是最佳做法？此外，我需要能够使用迁移。

更明确地说，可能的情况如下：

A）你创建了一个带有一些dbContextBase类和表（类）的.dll。

B）您创建其他以自己的方式依赖/扩展dbContextBase的.dll *

C）你在一个项目中引用了.dll并扩展它们。

所以基本上你可以有一个核心dbContext，然后添加一个菜单模块，然后你添加一个博客模块（但它可以通过菜单模块看到，以创建最新的博客文章菜单等）。最重要的是，如果您想要一个特定的博客一次性功能，您可以快速集成它，但也可以保持您的博客模块可更新。

我希望看到它的最佳方法是使用每个模块的模型（等）的源代码Nuget包，而不是编译的dll。

Answer 1

您可以在核心程序集中构建一些基础结构，这些基础结构将发现模块中的实体并将它们注册到单个上下文中。每个实体必须具有从EntityTypeConfiguration<>（或复杂类型的ComplexTypeConfiguration<>）派生的类，它将描述映射。

一旦有了映射类，就可以使用一些模块接口来为每个模块收集所有模块，或者使用反射来浏览程序集并创建映射类的实例。这些类可以直接在DbModelBuilder使用（在OnModelCreating或直接使用）。

  

此外，我需要能够使用迁移。

我不确定迁移是否已准备就绪，因为它有一些先决条件：

• 所有共享表必须由核心程序集处理 - 它自己的DbMigration派生类（或新版本的类）
• 每个模块必须处理自己的表 - 它自己的DbMigration派生类（或新版本的类）
• 模块不得更改共享表
• 模块不得更改或访问其他模块的表格

这意味着您为核心设置了特殊迁移，并为每个模块设置了一个迁移设置。每个迁移集都在单独的程序集中定义 - 这可能是潜在的问题。我自己没有尝试过，所以我不知道EF迁移是否可以解决这个问题 - 我特别针对您真正需要模块化系统的情况，其中模块可以随着时间的推移添加或删除，因此您需要同时安装（Up方法）和卸载（Down方法）。

迁移的问题在于，如果您开发平台，人们可以添加您不知道的自定义模块（如果它们不会破坏您的核心），那么您必须这样做，而且必须不能这样做。

Answer 2

由于我没有按照我的方式专注于问题的答案，我现在发布一个答案，其中似乎是最好的解决方法。

为了完全支持迁移，甚至是自定义迁移，以及对代码优先设计的全面支持，最好的方法是导入源代码并直接编译。

我们正在使用本地nuget Feed，以便能够自由快速地同步多个子模块。这也可以带来良好的更新体验，因为可以在需要时轻松创建或导入/集成迁移

Answer 3

这个场景怎么样：一个带有一些实体的DbContext，在OnModelCreating上，查找外部程序集上的其他类，这些类继承自此DbContext所在程序集的基类。我希望能够根据这些类更新已创建的数据库，假设它们不更改基表，只能添加新的数据库。这可能吗？到目前为止，根据我的经验，使用MigrateDatabaseToLatestVersion，它只是忽略了新实体，即不生成任何新表。