具有相同/单个数据库的单独IdentityDbContext-有什么好处？

Posted 2023-01-13

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

我以前见过应用程序使用两个单独的数据库上下文，但是每次它们通过IdentityDbContext使用一个单独的数据库时。也许以前的开发人员正在尝试实现我不清楚的事情。

因此，在应用程序只有一个数据库的情况下使用两个单独的上下文的情况下，可能会缺少哪些可能的优势？谢谢。

编辑：

我的理解是，由于我只有一个数据库，因此我可以轻松地仅使用IdentityDbContext，它可以满足目前两个单独上下文结合使用的所有目的。该应用程序具有各种业务实体（例如，雇员，客户，供应商等），这些实体不是应用程序的User，但是可以在将来的某个时刻通过注册具有相应角色权限的级别而成为一个实体。在这种情况下，仅使用IdentityDbContext可为我提供与AspNetUsers表建立一对一关系的优势，由于单独的上下文，我现在无法实现该关系。

答案

唯一的真正的“优势”是，它是轻微的，它更符合有限的上下文哲学：每个上下文只能与特定的子域一起使用。但是，实际上，您还应该同时拥有单独的数据库，否则您仍在混合上下文。另外，如果所有这些都在同一个项目中，那么零点就全都了。在这种情况下，即使有界上下文的想法也是有争议的，因为最终只有一个域。

[很有可能，这不是故意的，而是偶然的。当您使用个人用户帐户创建新项目时，将添加IdentityDbContext派生的类以支持脚手架。您可以简单地修改此脚手架上下文以包括您自己的其他实体，但是尤其是更多的绿色开发人员通常只会为应用程序的实体添加其他上下文类。他们俩都使用相同的基础数据库，这一事实仅使人相信这可能会发生。

简而言之，没有真正的优势。唯一的好处是，如果您逐字地隔离这些上下文，以使这两个上下文永远不会同时供同一项目使用，即它们生活在单独的类库中，并且根据应用程序的特定域添加了一个或另一个引用。正在维修。缺少这一点，这完全没有意义。

另一答案

这是基于具有单一责任和关注点分离的设计。

单独的上下文是不与其他上下文共享表的上下文。无论表位于何处。

身份框架的职责是使用其自身的上下文来识别用户。而应用程序具有业务上下文来存储与业务相关的数据。两者具有不同的职责，并且除了可以用于绑定两者的userid（或子声明）之外，这两种上下文实际上没有任何共同之处。

简而言之，我可以分开关注，而无需破坏我的应用程序。换句话说，当我决定为Identity Manager4之类的sso实现替换身份时，转移了职责，那么我将毫不费力地将用户迁移到Identity Provider的单独表。

使用单个应用程序，您可能无法分辨出区别，但是一旦应用程序成为具有多个API的更大平台的一部分，或者当需要替换标识用户的责任时，它将付清。

但是对于单个应用程序，我建议分开关注。当上下文分开时，您将需要一个好的设计。由于Identity的更改不会影响应用程序，反之亦然，它提高了可维护性并且更易于测试。

它还可以防止混合不应被混合的信息。例如。您只想显示用户名，就不想泄漏哈希密码。

出于安全原因，业务应用程序不应有权访问身份上下文，并且身份提供者应保持对业务上下文的了解。如果信息丢失，则应确保它成为上下文的一部分，但不要通过加入上下文来实现。

混合上下文的问题是，最终，所有这些都变成一个上下文。这意味着所有表很可能都必须成为Identity上下文的一部分。请阅读我的答案here，以获取有关此问题的更多想法。

也请考虑单独的授权上下文。请阅读我的答案here了解更多详细信息。