Search code examples
c#entity-frameworkpocodomain-model

How to use AspNet.Identity in a Domain Model


A domain model should model the problem domain of an application, but be completely unaware of certain aspects of its implementation; data access for example.

In this respect, it feels a bit dirty adding Microsoft.AspNet.Identity.EntityFramework to the domain model, since the domain model should be unaware (and not care) that I'm going to implement it using Entity Framework...

...herein lies my problem

In my domain model I have several classes which are linked to user accounts

Example

class Profile
{
    public User Owner { get; set; }
}

class BlogPost
{
    public User Owner { get; set; }
}

The problem is that User extends IdentityUser, hence the reference to EntityFramework.

The only solution I can think of would be to replace references to User with Guid, just linking the Owner ID

Example

class Profile
{
    public Guid OwnerId { get; set; }
}

Again, this feels dirty, against OOP and not very SOLID

Given that I want as elegant-a-solution as possible, how can I solve this?


Solution

  • I agree with you that the Identity Framework model should be seperate from other models. And I think you give the answer yourself in your question. Is the model complete without implementing Identity Framework? User is not part of the domain model but part of the Identity model. However, you are linking to this table.

    I think the best solution is to create a domain User table and relate your model to this table. You can use the Identity Framework User GUID as key. This will create a 1:1 relation between the two tables.

    Extend the User class (from Identity framework) with the domain user table to easily access the domain user table, in case you need to add or remove a user. Despite the fact that domain.user is not part of the Identity Framework, you can access this table without having to add this table to the Identity Framework model itself. Just add a reference in User (IdentityUser) class.

    If you do not want to create a new User table then you can add a domain User class (that does not extend IdentityUser) that only exposes the (non-critical) fields you want to read or update.