为什么IdentityUser类在Microsoft.AspNet.Identity.EntityFramework命名空间中而不在Core包中？

Question

为什么IdentityUser包中的Microsoft.AspNet.Identity.EntityFramework类不是包含在Microsoft.AspNet.Identity.Core包中？

为什么它要依赖于EntityFramework？这似乎是一个简单的课程。

我错过了什么？

我通常将数据层与我的DAL分开。为EntityFramework类添加IdentityUser依赖关系似乎有点多了。

Answer 1

Identity的核心设计不与EF或任何特定形式的用户和角色类型相关联。一切都被商店抽象出来。实际上，对于任何给定的持久性提供程序，类型甚至根本不需要是POCO！

对于Identity 3.0，我们考虑将我们当前的类型放在核心中（事实上，在某些时候我们已将它们放在那里）但是我们从熟悉其他持久性框架的人那里获得了非常可靠的反馈，尽管这些类型可以符合通用的定义“POCO”，它们非常符合EF。

我们还考虑在核心中使用基类，我们将在EF包中扩展EF。我们降落在原地，因为这似乎没有足够的好处。在添加额外继承层的复杂性（更复杂性会使我们更容易引入错误）与类型本身不那么复杂以及持久性提供者编写者想要将它们作为起点欢迎复制＆amp;粘贴代码。

Answer 2

你问：

  

为什么IdentityUser类在   Microsoft.AspNet.Identity.EntityFramework包...为什么要这样   依赖于EntityFramework？

这是因为Identity的开箱即用实现实际上取决于实体框架。

ASP.NET站点包含以下文章： Overview of Custom Storage Providers for ASP.NET Identity表示：

  

默认情况下，ASP.NET Identity系统将用户信息存储在   SQL Server数据库并使用Entity Framework Code First创建   数据库。对于许多应用，这种方法效果很好。   但是，您可能更喜欢使用不同类型的持久性   机制，例如Azure表存储，或者您可能已经拥有   结构与默认结构非常不同的数据库表   实现。无论哪种情况，您都可以编写自定义提供程序   为您的存储机制和插件提供商   应用

同一页面也应该在关于创建IUser的自定义实现的评论中回答您的问题：

  

自定义用户类

     

实施自己的存储提供程序时，必须创建用户   class，相当于中的IdentityUser类   Microsoft.ASP.NET.Identity.EntityFramework命名空间：