EF:寻找模块化应用程序的DatabaseFirst DbContext的设计策略

Question

我正在寻找有关如何在模块化非单片应用程序设计中使用ORM(在本例中为EF5)的建议,其中包含Core部分和第三方模块,其中Core没有直接引用第三方模块和模块仅引用Core/Common表和类.

为了论证,一个足够接近的类比将是DNN.

CodeFirst:

使用CodeFirst,我使用的方法是通过反射构建Db的模型:在Core的DbContext的DbInitialation阶段,我使用Reflection来查找任何用IDbInitializer(自定义)修饰的dll(例如Core或各种模块)中的任何类包含Execute()方法的契约,只定义dll的结构.每个dll都向DbModel添加了它自己知道的内容.任何后续的Seeding也在同一个wa中处理(搜索特定的IDbSeeder合同并执行它).

亲:*这种方法现在有效.*可以在所有存储库中使用相同的核心DbContext,只要每个存储库使用dbContext.GetSet(),而不是期望它是dbContext的属性.没什么大不了的.缺点:*它仅在启动时有效(即添加新模块需要AppPool刷新).*CodeFirst非常适合POC.但在EF5,它不够成熟的企业工作但(我不能等待EF6的StoredProcs和其他功能添加).*我的DBA讨厌CodeFirst,至少对于Core来说,希望尽可能多地使用Stored Procs来优化那个部分......我们是一个团队,所以我必须设法找到一种方法来取悦他,如果我能想办法...

数据库一:

DbModel阶段似乎发生在DbContext的构造函数之前(从嵌入的*.edmx资源文件中读取).永远不会调用DbInitialization(因为模型被认为是完整的),所以我不能添加比Core知道更多的表.

如果我不能动态地向模型添加元素,就像使用CodeFirst一样,这意味着*Core DbContext的模型必须知道Db - Core和每个第三方模块中的每个表.使应用程序单片和高度耦合,击败我想要实现的东西.*或者每个第三方必须创建自己的DbContext,导入Core表,导致*版本问题(模块在更新Core的*.edmx时不更新其*.edmx等等)*复制无处不在,在不同的内存环境中=难跟踪并发问题.

在这一点上,在我看来,CodeFirst方法是使用EF实现Modular软件的唯一方法.但希望其他人知道如何使DatabaseFirst大放异彩 - 有没有办法将DbSet'附加'到嵌入式*.edmx文件创建的模型中？

还是其他任何想法？

Answer 1

虽然它是 CodeFirst 方法，而不是最干净的解决方案，但即使在启动后也强制初始化运行怎么样，如此处发布的答案：强制代码优先始终初始化不存在的数据库？（我对 CodeFirst 一无所知，但鉴于这已经一个月了，还没有任何帖子，所以值得一试）