架构和ASP.Net身份

Question

我目前正在遵循以下GitHub，以获取有关将用户数据从ASP.Net Identity存储到Mongo的指导： https : //github.com/g0t4/aspnet-identity-mongo 。 有了基本的概念证明，我就能够成功存储用户数据。 我当前面临的问题是我的应用程序需要两种类型的用户（这两种类型的用户都将存储到同一Mongo集合中）。

为简单起见，我们可以称呼用户A和B。A和B都被设置为模型并具有自己的属性。 我最初的想法是将A和B都设置为ApplicationUser的派生类（请参见参考存储库中的IdentityModels.cs文件）。

在该应用程序中的注册与该体系结构完美配合，并且JSON文档已发布/存储到我的MongoDB中。 问题是当我尝试登录时。 发布后，出现服务器错误：

元素与Models.ApplicationUser类的任何字段或属性都不匹配

当我将模型A的所有元素都放入ApplicationUser时，错误消失了。 但是，这使得模型B的问题没有得到解决。 因此，我想问一问我采取的最佳途径是什么？ 我想到的一些想法涉及创建两个唯一的UserManager，使用一个包含所有元素的大型JSON文档（似乎有点杂乱无章），或者使用一个UserManager和两个模型的适配器？

Answer 1

设置的方式很好，应该如此。 问题似乎出在Mongo如何处理继承上，尽管对于SQL Server之类的东西您仍然会有另一个不同但同样成问题的问题。

简而言之，这里发生的事情实际上是您将UserA / UserB为ApplicationUser ，但是由于JSON包含那些派生类的属性，而ApplicationUser没有，所以Mongo对此感到窒息。 解决方案是使用多个UserManager 。 这是一个通用类型，需要一个TUser类型参数。 默认实现为UserManager<ApplicationUser> ，但假定所有内容均为ApplicationUser 。 如果已派生用户类型，则需要为其使用特定于类型的UserManager<TUser>实例，即UserManager<UserA>和UserManager<UserB> 。

FWIW，您在另一个数据存储区上遇到的问题是，保存的类型决定了添加的Discriminator列的值，以使用查询实例化正确的类型。 例如，即使您正在创建UserA ，如果您使用UserManager<ApplicationUser>的实例，它也会被上载到ApplicationUser并另存为ApplicationUser ，而不是UserA 。 这类似于您在Mongo设置中发生的事情，但是类似SQL Server的东西会很乐意接受（尽管您的数据随后会被弄乱），而Mongo却在出错。

总而言之，请始终使用特定于您正在使用的用户类型的UserManager<TUser>实例。