dbcontext - 使用相同的数据库将身份和业务操作的 DbContext 分开 - 有什么优势吗？

Question

我已经开始研究使用 Identity 框架的现有 ASP.NET Core 项目。该应用程序使用单个数据库。出于某种原因，应用程序使用两个独立的数据库上下文 - 一个派生自 IdentityDbContext哪个当然用于管理 User/Auth 和另一个派生自 DbContext用于用户相关业务以外的任何其他业务。

我以前见过使用两个单独的数据库上下文的应用程序，但每次它们都通过 IdentityDbContext 使用单独的数据库。 .也许以前的开发人员试图实现我不清楚的东西。

那么，在我使用两个单独的上下文而应用程序具有单个数据库的场景中，我可能缺少哪些可能的优势？谢谢。

编辑:

我的理解是，由于我只有一个数据库，因此我可以轻松地仅使用 IdentityDbContext它将服务于目前两个单独的上下文组合所服务的每一个目的。该应用程序具有各种业务实体(比方说员工、客户、供应商等)，它们不是 User的应用程序，但可以在 future 的某个时间点通过注册具有各自基于角色的权限级别。在这种情况下，仅使用 IdentityDbContext给了我与 AspNetUsers 建立一对一关系的优势表，因为单独的上下文，我现在无法实现。

Answer 1

唯一真正的“优势”是它更符合有界上下文哲学:每个上下文应该只适用于特定的子域。但是，实际上，您还应该拥有单独的数据库，否则您仍在混合上下文。此外，如果这一切都在同一个项目中，那么无论如何都是零分。在这种情况下，即使是有界上下文的想法也是有争议的，因为最终只有一个域。

更有可能的是，这更像是意外而不是故意。当您使用个人用户帐户创建新项目时，IdentityDbContext添加了-派生类，以支持脚手架。您可以简单地修改这个脚手架上下文以包含您自己的附加实体，但特别是更多的绿色开发人员通常只会为应用程序的实体添加一个附加的上下文类。他们都使用相同的底层数据库这一事实只会让人相信这是可能发生的事情。

简而言之，没有真正的优势。唯一的好处是，如果您真的将这些上下文隔离开来，使得这两个上下文永远不会同时对同一个项目可用，即它们位于不同的类库中，并且添加了一个或另一个引用，具体取决于应用程序的特定域正在维修。否则，完全没有意义。