MVC Layered Project Structure

Question

We are starting a new web project using C# / MVC 4 and Entity Framework 5 for data access. I've decided to go with an n-layered approach for the structure of the project and I would like some feedback on my design decisions.

This is how the solution is structured:

Project.Model (Class Library): Contains EF .edmx, entity models, and view models

Project.DAL (Class Library): Contains EF DbContext and Repository classes

Project.BLL (Class Library): Contains business logic classes

Project (MVC Project)

DAL

The Data Access Layer is only concerned with simple CRUD like operations. I've decided to go with a repository approach. Here are the Repository interfaces:

public interface IRepository
{
}

public interface IRepository : IRepository, IDisposable 
    where T : class, new()
{
    T Add(T item);

    T Get(object id);

    T Get(Expression> predicate);

    IQueryable GetAll();

    IQueryable GetAll(Expression> predicate);

    void Update(T item);

    void Delete(T item);
}

After doing some research on using Entity Framework in web projects, the general consensus is that there should only be one DbContext/ObjectContext per request. So to create and dispose the single context for each request, I've written an HttpModule that injects the DbContext into the HttpContext.

public class DbContextModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.BeginRequest += context_BeginRequest;
        context.EndRequest += context_EndRequest; 
    }

    public void Dispose()
    {
    }

    private void context_BeginRequest(object sender, EventArgs e)
    {
        HttpApplication application = (HttpApplication)sender;
        HttpContext httpContext = application.Context;

        httpContext.Items.Add(Repository.ContextKey, new ProjectEntities());
    }

    private void context_EndRequest(object sender, EventArgs e)
    {
        HttpApplication application = (HttpApplication)sender;
        HttpContext httpContext = application.Context;

        var entities = (ProjectEntities)httpContext.Items[Repository.ContextKey];

        entities.Dispose();
        entities = null;

        application.Context.Items.Remove(Repository.ContextKey);
    }
}

Next is the Repository base class. Note that the constructor utilizes the injected DbContext from the HttpModule above

public abstract class Repository : IRepository where T : class, new()
{
    protected Repository()
    {
        if (HttpContext.Current == null)
        {
            throw new Exception("Cannot create repository - current HttpContext is null.");
        }

        _entities = (ProjectEntities)HttpContext.Current.Items[Repository.ContextKey];

        if (_entities == null)
        {
            throw new Exception("Cannot create repository - no DBContext in the current HttpContext.");
        }
    }

    private ProjectEntities _entities;

    public T Add(T item)
    {
        _entities.Set().Add(item);
        _entities.SaveChanges();

        return item;
    }

    public T Get(object id)
    {
        return _entities.Set().Find(id);
    }

    public T Get(Expression> predicate)
    {
        return _entities.Set().AsQueryable().FirstOrDefault(predicate);
    }

    public IQueryable GetAll()
    {
        return _entities.Set().AsQueryable();
    }

    public IQueryable GetAll(Expression> predicate)
    {
        return _entities.Set().AsQueryable().Where(predicate);
    }

    public void Update(T item)
    {
        _entities.Entry(item).State = EntityState.Modified;
        _entities.SaveChanges();
    }

    public void Delete(T item)
    {
        _entities.Set().Remove(item);
        _entities.SaveChanges();
    }
}

And a simple example of an implementation...

public class AdminRepository : Repository
{
    public Admin GetByEmail(string email)
    {
        return Get(x => x.Email == email);
    }
}

BLL

The Business Logic Layer encapsulates all business logic. To keep constraints, I've written the base "Logic" class like this:

public abstract class Logic where TRepository : class, IRepository, new()
{
    private static Expression> _x = () => new TRepository();
    private static Func _compiled = _x.Compile(); 

    protected Logic()
    {
        Repository = _compiled();
    }

    protected internal TRepository Repository { get; private set; }
}

The constructor automatically creates the needed Repository class, so no additional code is needed in child classes to instantiate the repository. Here is a simple example of an implementation

public class AdminLogic : Logic
{
    public Admin Add(Admin admin)
    {
        return Repository.Add(admin);
    }

    public Admin Get(object id)
    {
        return Repository.Get(id);
    }

    public Admin GetByEmail(string email)
    {
        return Repository.GetByEmail(email);
    }

    public IQueryable GetAll()
    {
        return Repository.GetAll();
    }

    public void Update(Admin admin)
    {
        Repository.Update(admin);
    }
}

This example is more of a pass-through for the DAL repository, but adding business logic later won't be a problem. I'm choosing to return IQueryable from the BLL because we are using some third party tools that require an IQueryable for deferred execution.

Project (MVC Project)

Now finally here is what a simple controller action will look like:

public ActionResult Index(int? page)
{
    // Instantiate logic object
    AdminLogic logic = new AdminLogic();

    // Call GetAll() and use AutoMapper to project the results to the viewmodel
    IQueryable admins = logic.GetAll().Project().To();

    // Paging (using PagedList https://github.com/TroyGoode/PagedList)
    IPagedList paged = admins.ToPagedList(page ?? 1, 25);

    return View(paged);
}

Everything works as expected, and tests show that the EF context is properly disposed and the overall speed is good.

Is this a pretty good way to go about this?

Thank you for your time.

MVC Layered Project Structure

Answers (1)

Related Questions