Repository Design Pattern in MVC Architecture With Entity Framework

The MVC framework is one of the common design patterns in modern web applications. It provides a complete separation of concerns. But even MVC is not a silver bullet for all problems. On top of MVC, we can implement various design patterns to solve the specific problem.

In this example, we will first implement a sample application using pure MVC architecture and then we will see how to improve our code standards by implementing the repository design pattern. So, let's start with one example.

I will suggest you create one MVC application. Let's create the table first then we will set up the Entity Framework in the application. Here is the table structure.

We have added the Entity Framework file (.edmx) file and the model is like this.

Now let's implement a Company controller and implement CRUD operations. Have a look, we have messed up the database operations within the controller. Now if you decide to change it, how will you implement your data access layer? Right now, the Contact Manager application uses the Microsoft Entity Framework to access the database. However, you might decide to migrate to a new or alternative data access technology such as ADO.NET Data Services or NHibernate. However, because the data access code is not isolated from the controller code, there is no way to modify the data access code in your application without modifying other code that is not directly related to data access. Have a look at the following example.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;

namespace MVC.Controllers
{
    public class CompanyController : Controller
    {
        efDBEntities _db = null;

        public CompanyController()
        {
            _db = new efDBEntities();
        }

        // Read All company Information
        public string Index()
        {
            var company = _db.company.ToList();
            return View(company); // Changed 'view' to 'View'
        }

        // Create new company
        public ActionResult Create(company comp)
        {
            var insertedCompany = _db.company.Add(comp);
            _db.SaveChanges();
            return RedirectToAction("Index");
        }

        // Update Existing company
        public ActionResult Update(company comp)
        {
            var company = _db.company.Where(f => f.cid == comp.cid).FirstOrDefault();
            if (company != null)
            {
                company.company_name = comp.company_name;
                _db.SaveChanges();
                return RedirectToAction("Index");
            }
            throw new ArgumentException();
        }

        // Delete company
        public ActionResult Delete(int? id) // Changed 'Int32 ?' to 'int?'
        {
            var company = _db.company.Where(f => f.cid == id).FirstOrDefault(); // Changed '1' to 'id'
            if (company != null)
            {
                _db.Entry(company).State = System.Data.EntityState.Deleted;
                _db.SaveChanges();
                return RedirectToAction("Index");
            }
            throw new ArgumentException();
        }
    }
}

Ok, we understand the problem; how to solve it? The solution is the Repository Design Pattern, we will totally isolate the DB operation part into a different class and we will consume the service (yes, let's think of the class as a service class) into our actual controller class.

For that, at first, we will create an interface and a repository for CRUD operations, and then we will implement the interface within the concrete class.

So, the following is the Interface implementation.

public interface ICompany
{
    bool Create(company Company);
    company Read(int Id);
    IEnumerable<company> Read();
    bool Update(int Id, company Company);
    bool Delete(int Id);
}

There are five functions within this Interface that we will implement in a class shortly. Here, we have implemented an ICompany interface within a “CompanyRepositary” class. Have a look at the following example.

Repository class for CRUD operation

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace MVC.Models
{
    public class CompanyRepository : ICompany
    {
        efDBEntities _db = new efDBEntities();

        public bool Create(company Company)
        {
            if (Company != null)
            {
                // Insert data into database
                using (var comp = new efDBEntities())
                {
                    comp.company.Add(Company);
                    comp.SaveChanges();
                    return true;
                }
            }
            throw new ArgumentException();
        }

        public company Read(int Id)
        {
            if (Id > 0)
            {
                // Read company information
                return _db.company.Where(f => f.cid == Id).FirstOrDefault();
            }
            throw new ArgumentException();
        }

        public IEnumerable<company> Read()
        {
            // Read all company information
            return _db.company.ToList();
        }

        public bool Update(int Id, company Company)
        {
            var comp = _db.company.Where(f => f.cid == Id).FirstOrDefault();
            if (comp != null)
            {
                comp.company_name = Company.company_name;
                _db.SaveChanges();
                return true;
            }
            throw new ArgumentException();
        }

        public bool Delete(int Id)
        {
            var comp = _db.company.Where(f => f.cid == Id).FirstOrDefault();
            if (comp != null)
            {
                _db.company.Remove(comp); // Added line to actually remove the entity
                _db.SaveChanges();
                return true;
            }
            throw new ArgumentException();
        }
    }
}

We will now consume the repository service within our actual controller class. Here is the controller implementation. Now, have a look that, we have totally isolated the DB operation from our controller class. So, now the Company controller is de-coupled in nature and we have injected a dependency through the controller.

Implementation of Company repository in the controller

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using MVC.Models;

namespace MVC.Controllers
{
    public class CompanyController : Controller
    {
        ICompany _comp = null;

        // Default Constructor
        public CompanyController() : this(new CompanyRepository()) { }

        public CompanyController(ICompany tmpCompany)
        {
            _comp = tmpCompany;
        }

        // Read all company information
        public ActionResult Index()
        {
            return View(_comp.Read());
        }

        // Create new company
        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult Create([Bind(Exclude = "Id")] company comp)
        {
            if (_comp.Create(comp))
            {
                return RedirectToAction("Index");
            }
            else
            {
                return View();
            }
        }

        // Update existing company
        [AcceptVerbs(HttpVerbs.Put)]
        public ActionResult Update(int Id, company comp)
        {
            if (_comp.Update(Id, comp))
            {
                return RedirectToAction("Index");
            }
            else
            {
                return View();
            }
        }

        // Delete company
        [AcceptVerbs(HttpVerbs.Delete)]
        public ActionResult Delete(int Id)
        {
            if (_comp.Delete(Id))
            {
                return RedirectToAction("Index");
            }
            else
            {
                return View();
            }
        }
    }
}

The great advantage of this de-coupled architecture is unit testing. If we create one mock repository class and inject it in a controller then we can avoid execution of the DB part at the time of unit testing. I am interested in implementing and showing it in my next article. So, please follow my next article here.