每个数据库上下文都应该在自己的 Visual Studio 项目中吗？答案

【问题标题】：Should each database context be in its own Visual Studio Project?每个数据库上下文都应该在自己的 Visual Studio 项目中吗？
【发布时间】：2012-08-07 19:27:27
【问题描述】：

我有一个名为 MyApp.DataAccess 的项目，其中包含多个数据库上下文。这从一个上下文开始，已经发展到三个（我的应用程序需要所有单独的数据库）。正如你可以想象的那样，我也有每个初始化器类，我现在也在尝试使用迁移。我可以看到这确实会弄乱我的 MyApp.DataAccess 项目。

我还有一个名为 MyApp.Model 的项目，其中包含模型类，这些模型类通常根据它们在上述每个上下文中的用途组织在文件夹中。

我正在为如何最好地组织多个 DbContexts 和 Model 类而苦恼。

我的直觉告诉我选项 1，但最佳做法是什么？

为每个包含 DbContext、迁移和相关模型类的 DbContext 创建一个 MyApp.DataAccess.[ContextName] 项目。最终我仍然需要一个 MyApp.Model 项目来表示非数据库模型类。
为每个仅包含 DbContext 和迁移的 DbContext 创建一个 MyApp.DataAccess.[ContextName] 项目；继续将 MyApp.Model 用于所有模型类（按文件夹和子命名空间组织）。
什么都不做——一个带有多个 DbContexts、多个迁移等的 MyApp.DataAccess；单个 MyApp.Model，其中包含按文件夹组织的多个数据库的模型。

最佳实践/理想方法是什么？

【问题讨论】：

标签： ef-code-first entity-framework-migrations

【解决方案1】：

您的问题应该从“为什么我应该有不同的 DbContexts”开始。在大多数情况下，不同的上下文意味着不同的数据模型、不同的——不相关的——职责，因此应该尽可能地分开。这意味着不同的程序集正在运行。

【讨论】：

我想和你争论一下，不管不顾地为所有东西创建单独的项目，因为这可能导致过度设计和缓慢加载/构建项目......但在这种情况下你是对的。
仅供参考，您的回答确实有点刻薄……您的头衔必须是建筑师。 :-)
@kingdango 您还应该记住，程序集为您提供封装，允许向消费者隐藏所有不相关的（与域）类（如映射、迁移甚至 DbContext）。