ASP.NET MVC 4 – Integrating Entity Framework 5 and SimpleMembership into Repository and Unit Of Work Pattern

asp.net-mvc-4entity-framework

I have a ASP.NET MVC4 project in which I would like to use the SimpleMembership. The application has a Person table that holds relevant information about users in the system.

I would like a link between the currently logged in user and the Person information. So I have made a foreign key in the Person table to the UserId column of UserProfile table (from SimpleMembership).

I use Entity Framework 5 as ORM and have implemented a generic repository to handle CRUD methods and so on.

Now I am at a point where I want to implement user profile creation. The creation consists of 2 parts parts:

login: username and password (to be stored in SimpleMembership tables)
personal information (to be stored in Person table)

In order to create a user I guess I need to:

Save user information through SimpleMembership
Save personal information together with userId from step 1 through my PersonRepository

I would like some kind of UserRepository that could save SimpleMembership data but I do not know if it's the right approach?
Is there a better approach?

Best Answer

I always keep repositories so there a is a one to one relationship between a repository and a table in a database. And repositories do not know about other repositories. If you need to handle transactions between repositories I would implement a Unit of Work design pattern and on top of that a Service design pattern that handles the domain logic around the transactions.

Another option is to modify the UserProfile in SimpleMembership to contain the extra information that you have in the Person table. UserProfile was designed to be customized and you can read about customizing it here.

Related Solutions

Why Avoid Using Repository Pattern with Entity Framework?

I don't see any reason for the Repository pattern to not work with Entity Framework. Repository pattern is an abstraction layer you put on your data access layer. Your data access layer can be anything from pure ADO.NET stored procedures to Entity Framework or an XML file.

In large systems, where you have data coming from different sources (database/XML/web service), it is good to have an abstraction layer. The Repository pattern works well in this scenario. I do not believe that Entity Framework is enough abstraction to hide what goes on behind the scenes.

I have used the Repository pattern with Entity Framework as my data access layer method and am yet to face a problem.

Another advantage of abstracting the DbContext with a Repository is unit-testability. You can have your IRepository interface to which has 2 implementations, one (the real Repository) which uses DbContext to talk to the database and the second, FakeRepository which can return in-memory objects/mocked data. This makes your IRepository unit-testable, thus other parts of code which uses IRepository.

public interface IRepository
{
  IEnumerable<CustomerDto> GetCustomers();
}
public EFRepository : IRepository
{
  private YourDbContext db;
  private EFRepository()
  {
    db = new YourDbContext();
  }
  public IEnumerable<CustomerDto> GetCustomers()
  {
    return db.Customers.Select(f=>new CustomerDto { Id=f.Id, Name =f.Name}).ToList();
  }
}
public MockRepository : IRepository
{
  public IEnumerable<CustomerDto> GetCustomers()
  {
    // to do : return a mock list of Customers
    // Or you may even use a mocking framework like Moq
  }
}

Now using DI, you get the implementation

public class SomeService
{
  IRepository repo;
  public SomeService(IRepository repo)
  {
     this.repo = repo;
  }  
  public void SomeMethod()
  {
    //use this.repo as needed
  }    
}

Php – Repository Pattern: Doctrine2 vs Microsoft Entity Framework

I think what confuses you about EF is the database context. It allows you to query objects like a Repository and save changes in persistence like a Unit of Work.

You have a lot of work done with EF database context. All you have to do is segregate the responsibilities by creating specific repositories and a unit of work that share the database context and pesists all changes in presistence with a single save call.

Check this link about create Repositories and UoW in EF. It is clear and easy to understand.

Best Answer

Related Solutions

Why Avoid Using Repository Pattern with Entity Framework?

Php – Repository Pattern: Doctrine2 vs Microsoft Entity Framework

Related Topic