使用 MVC5 时，我为所有业务数据添加了一个域层和存储层，使用依赖注入。 但是我总是将ApplicationDbContext留在主要的MVC应用程序层项目中。
我读了很多关于SO的文章，看到很多人建议将ApplicationDbContext移出MVC项目。 我想了解为什么应该或不应该移动ApplicationDbContext。 有什么理由不移动这个上下文吗？
一方面，ApplicationDbContext使用的数据模型建议将其移动到存储层，但这需要大型DTO。 另一方面，ApplicationDbContext 实际上主要与应用程序访问有关，无论如何，我都有单独的业务数据角色/权限功能。 一些SO帖子还建议检查应用程序层中的角色，而不是域层，但这似乎值得怀疑;我们不想检查域层中的业务角色吗？
所以我很困惑，在我开始将 ApplicationDbContext 移动到另一层之前，我想确保我做出了一个合理且明智的决定。
这不是必须的，但如果您正在执行 DDD 并且您的项目往往会变大，则建议这样做。
尽管 DDD 与实现细节无关，但 DDD 要求明确分离关注点。然后，应将域逻辑与基础结构分开。
你可以通过多种方式实现这种分离。一种方法是让单个项目包含域、应用程序和基础结构的文件夹，并将 DbContext 驻留在基础结构文件夹中。这适用于小型项目。
但是，在大型项目中，我建议您评估清洁体系结构，它将把这种分离带到项目级别。
我想了解为什么应该或不应该移动ApplicationDbContext。有什么理由不移动这个上下文吗？
它可以被移动，没有规则反对它。但是该工具随后将要求您将启动项目和数据库项目都指定为参数，如下所示：
dotnet ef database update --project <path> --startup-project <path>
但由于使用的是 MVC5，因此可能没有使用 EF Core。对于 EF 6 或更低版本，你将使用包管理器控制台 (PMC) 来管理迁移和数据库更新，这将使你在这方面的工作更轻松，因为你可以从上下文菜单中将 MVC 项目标记为启动项目，并从 PMC 的下拉控件中选择目标项目。
一些SO帖子还建议检查应用程序层中的角色，而不是域层，但这似乎很可疑;我们不想检查域层中的业务角色吗？
是的，角色与权限相关，权限是业务规则。人们可能建议在应用程序层中检查它，因为您需要从数据库中提取此数据，但您可以这样做：
使用规范模式将角色和权限表示为域层中的规范。但 IRepository 接口最好在应用层中定义，因为它们表示基础结构(将在基础结构层中具体实现)。因此，您将通过使用存储库检索数据来启动应用程序层中的角色检查，但实际的权限验证将由域层中的规范完成。
这将是这样做的一种方式。