使用同一数据库将DbContext用于身份和业务操作分开-是否有优势? [英] Separate DbContext for Identity and business operations with same database - is there any advantages?

问题描述

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

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

那么，在我的应用程序只有一个数据库的情况下使用两个单独的上下文的情况下，可能会缺少哪些可能的优势?谢谢.

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

解决方案

唯一真正的优点"是，它更符合有限的上下文哲学:每个上下文只能与特定的子域一起使用.但是，实际上，您还应该同时拥有单独的数据库，否则您仍在混合上下文.另外，如果所有这些都在同一个项目中，那么零点就到了.在这种情况下，甚至连受限上下文的想法都是一个争论点，因为最终只有一个域.

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

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

I've started working on an existing ASP.NET Core project that uses the Identity framework. The application uses a single database. For some reason the application uses two separate database contexts - one derived from IdentityDbContext which of course is used for managing User/Auth and the other derived from DbContext which is used for anything other than User-related business.

I've seen previously applications using two separate database contexts, but every time they were using a separate database through the IdentityDbContext. Maybe the previous developer(s) were trying to achieve something not clear to me.

So, what could be some possible advantages, which I might be missing, in my scenario of using two separate contexts while the application have a single database? Thanks.

Edit:

My understanding is, since I have a single database I could easily use only the IdentityDbContext and it would serve every purpose which currently two separate contexts combined are serving. The application has various business entities (let's say Employee, Customer, Supplier, etc) which are not User of the application, but can be made one at some future point by registration with respective level of role-based privileges. In such a scenario, using only the IdentityDbContext gives me the advantage of creating one-to-one relationship with the AspNetUsers table, which I cannot implement now simply because of the separate contexts.

解决方案

The only real "advantage", and it's slight, is that it conforms more to a bounded contexts philosophy: that each context should only work with a particular subdomain. However, in practical terms, you should also then have separate databases as well, or you're still mixing contexts. Additionally, if this is all in the same project, then there's zero point whatsoever. Even the idea of bounded contexts is a moot point in that scenario, since there's ultimately just one domain.

More likely than not, this was more accidental than intentional. When you create a new project with Individual User Accounts, an IdentityDbContext-derived class is added, to support the scaffolding. You can simply modify this scaffolded context to include your own additional entities, but particularly more green developers will often just add an additional context class for the app's entities. The fact that they're both using the same underlying database only leads credence to this being what likely occurred.

In short, there is no real advantage. The only benefit would come if you literally segregated these contexts such that the two were never available to the same project at the same time, i.e. they lived in separate class libraries and one or the other reference was added, depending on the particular domain the app is servicing. Short of that, it's entirely without point.

这篇关于使用同一数据库将DbContext用于身份和业务操作分开-是否有优势?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！