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

Question

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

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

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

编辑：

我的理解是，由于我只有一个数据库，因此我可以轻松地只使用 ，IdentityDbContext并且它可以满足当前两个单独的上下文组合所服务的每个目的。该应用程序具有各种业务实体（比如员工、客户、供应商等），这些实体不User属于该应用程序，但可以在未来某个时间点通过使用基于角色的各个级别的权限进行注册来使其成为一个。在这种情况下，仅使用IdentityDbContext给了我与AspNetUsers表创建一对一关系的优势，我现在无法仅仅因为单独的上下文而实现。

Answer 1

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

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

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