10

Why is the IdentityUser class in the Microsoft.AspNet.Identity.EntityFramework package instead of being included in the Microsoft.AspNet.Identity.Core package?

Why should it depend on EntityFramework? It seems to be a simple class.

What am I missing?

I typically separate by Data layer from my DAL. Adding a dependency to EntityFramework for the IdentityUser class seems a bit much.

Issa Fram
  • 2,556
  • 7
  • 33
  • 63
  • Take a look at the following post: http://eliot-jones.com/2014/10/asp-identity-2-0 – David Tansey Jun 15 '15 at 00:08
  • @DavidTansey the post shows the author creating his own `MyUser` class implementing the `IUser` interface. The author manually added many of the typical properties found in `IdentityUser` to his custom class. Is that what people typically do? They don't use the custom `ApplicationUser` class which inherits from `IdentityUser` like most of the templates have in Visual Studio? – Issa Fram Jun 15 '15 at 00:24
  • @IssaFram: That's what you have to do if you don't want to depend on EntityFramework. At the bottom of this [page](http://www.asp.net/identity/overview/extensibility/overview-of-custom-storage-providers-for-aspnet-identity) there's a list of implementations of providers EF free. – LeftyX Jun 15 '15 at 10:37

2 Answers2

7

The design of the core of Identity is not coupled to EF or to any specific shape of user and role types. Everything is abstracted by the stores. In fact, for any given persistence provider, the types don't even need to be POCOs at all!

For Identity 3.0 we considered having our current types in core (in fact, at some point we had them there) but we got pretty solid feedback from people familiar with other persistence frameworks that although those types can comply to a common definition of "POCO", they are very EF specific.

We also considered having base classes in core that we would extend for EF in the EF package. We landed where we are because there didn't seem to be enough benefit in this. It was between adding the complexity of an extra layer of inheritance (more complexity would make it easier for us to introduce bugs) vs. the fact that the types themselves aren't that complex and that persistence provider writers who want to take them as a starting point are welcome to copy & paste the code.

divega
  • 6,320
  • 1
  • 31
  • 31
3

You asked:

Why is the IdentityUser class in the Microsoft.AspNet.Identity.EntityFramework package...Why should it depend on EntityFramework?

This is because the out-of-the-box implementation for Identity actually depends on Entity Framework.

The ASP.NET site has the following article: Overview of Custom Storage Providers for ASP.NET Identity which indicates:

By default, the ASP.NET Identity system stores user information in a SQL Server database, and uses Entity Framework Code First to create the database. For many applications, this approach works well. However, you may prefer to use a different type of persistence mechanism, such as Azure Table Storage, or you may already have database tables with a very different structure than the default implementation. In either case, you can write a customized provider for your storage mechanism and plug that provider into your application.

The same page also should answer your question in the comments about creating a custom implementation of IUser:

Customize the user class

When implementing your own storage provider, you must create a user class which is equivalent to the IdentityUser class in the Microsoft.ASP.NET.Identity.EntityFramework namespace:

Community
  • 1
  • 1
David Tansey
  • 5,813
  • 4
  • 35
  • 51
  • 1
    So are you saying that we can't remove any of the default included properties in `IdentityUser`? Like for example, if I don't want `PhoneNumber`, I can't remove that? I'm just trying to wrap my head around this. – Issa Fram Jun 19 '15 at 02:08
  • @David Tansey: this is correct, although a bit outdated for Identity 3.0. E.g. in Identity 3.0 there is no IUser interface. – divega Aug 17 '15 at 21:00
  • 1
    For Identity 2.0 If you don't want the base class and the properties, then you can inherit from IUser and register your POCO with UserManager. – pranav rastogi Aug 17 '15 at 21:30
  • @pranavrastogi that might've been the best answer yet. I saw `IUser` but that interface made no sense to me. – Issa Fram Aug 18 '15 at 15:17