ASP.NET MVC, EntityFramework, DBContext, Repository in a different Project [closed]

Question

Your question is pretty broad. For instance, what do you mean by the "the best way to access the database content using EF"? The best way in terms of performance?

I will try to answer by giving an option I prefer (of which I mostly use some variant), which uses the repository pattern. If you'd use your EF sets directly as a repository you might argue you wouldn't need the repository pattern, but I like to wrap those in one of my own.

Since I can't know what you mean by the best way, I'll give my personal preference which would suite a typical web project.

I won't be posting all the code to make it completely functional, but you should get a clear idea of what's going on.

Setup (4 projects):

UI ----------> Domain.Logic (w. Domain.Models) -----------------> Data (Holding the EF Context).

Data:

public partial class EFContextContainer : DbContext 
enter code here
public EFContextContainer ()
        : base("name=EFContextContainer")
    {
    }

public DbSet<IdentityUser> IdentityUsers { get;set; }

With a wrapper returning the context:

public static class Database
{
    public static EFContextContainerGetContext()
    {
        return new EFContextContainer();
    }

}

You could have a repository setup like this:

Interface:

public interface IRepository<T> where T : class
{
    IQueryable<T> GetAll();
    T GetById(Guid id);
    void Add(T entity);
    void Update(T entity);
    void Delete(T entity);
    void Delete(Guid id);
}

Implementation (only implemented the Add(T entity) for the sake of brevity):

public class EFRepository<T> : IRepository<T>, IDisposable where T : class
{
    public EFRepository(DbContext dbContext)
    {
        if (dbContext == null)
            throw new ArgumentNullException("dbContext");
        DbContext = dbContext;
        DbSet = DbContext.Set<T>();

    }

    protected DbContext DbContext { get; set; }

    protected DbSet<T> DbSet { get; set; }

    public virtual void Add(T entity)
    {
        DbEntityEntry dbEntityEntry = DbContext.Entry(entity);
        if (dbEntityEntry.State != EntityState.Detached)
        {
            dbEntityEntry.State = EntityState.Added;
        }
        else
        {
            DbSet.Add(entity);
        }
    }

public void Dispose()
    {
        DbContext.Dispose();
    }

}

Domain:

Domain.Logic (IdentityUserManager would be a class in Domain.Models):

public class IdentityUserManager
{
    public void Add(IdentityUser idUser)
    {
        using(var idUserRepository = new EFRepository<IdentityUser>(Database.GetContext())
        {
            idUserRepository.Add(idUser);
        }
    }
}

UI:

[HttpPost]
public ActionResult Post(UserViewModel model)
{
    UserIdentity user = MapUser(model);
    var userManager = new IdentityUserManager();
    userManager.Add(user);

    return View(new UserViewModel());
}

(This isn't all composed in Visual Studio, so forgive any spelling errors.)

Admitting, there can be a lot more abstraction in this code, but it would be ridiculous to pen down an entire solution here. For instance, you could use the Unit of Work pattern as well, which works great with the repository pattern. So read this a an example, not a full guide on how to implement this setup. Things could be set up a lot cleaner than this example.

For an in-depth view of the implementation of some of these patterns, I urge you to take a look into the course Single Page Apps by John Papa on Plural Sight. He does an excellent job explaining the benefits of these patterns and how to implement them.