In an ASP.NET MVC 5 application using Entity Framework 6, I'm learning about the Repository and Unit of Work patterns.
I've already read a ton of guides and articles, but nearly all of them contradict each other. Repository and Unit of Work patterns, according to some, are good. DbContext, on the other hand, is already a repository and a unit of work, according to others. I've tried a lot of various strategies—well, maybe not all of them—but I'm still not sure which is the best one.
What I have at the moment is:
I'm not sure if I need to paste the code because it seems to be quite generic and the issue isn't really with Repository/UnitOfWork per se. The problem I'm having is when I use my repositories and unit of work with ASP.NET Identity classes. I share the same database for membership and all other data, which I believe is a typical situation. I can't seem to find a viable way to use my repositories to instantiate ASP.NET Identity classes.
UserStore<ApplicationUser> store = new UserStore<ApplicationUser>(_DBCONTEXT_); this.UserManager = new UserManager<ApplicationUser>(store);
What should I substitute for DBCONTEXT in order for it to share the same DbContext as my UnitOfWork? Or how else may ASP.NET Identity be configured to function with UnitOfWork?
I tried making the UnitOfWork class' DbContext a public property, as in:
UserStore<ApplicationUser> store = new UserStore<ApplicationUser>(this.unitOfWork.MyDbContext);
However, I don't believe that is correct because it interferes with the use of the special IDbContext interface and renders the code unsuitable for unit testing.
Additionally, I attempted to implement CustomUserStore and CustomRoleStore; while generally successful, it required the implementation of an increasing number of methods as I tested it. I sincerely hope there is a simpler approach because this method appears to be too complex.