Projects are accessing data from various sources from
database, flat files to web services. The business layer of any particular
application consumes these accessed data in order to utilize in business logic.
The separation of concerns and the testability plays major role when we are
accessing data from various sources. The Repository design pattern provides us
generic solutions to these problems. Data access is not the only place where we
can use the repository pattern, but is the most used domain of this particular
design pattern.
Following diagram depicts a bird’s eye view of how the
repositories do the linkage between the data source and the business layer. The
Business logic would access in memory data from the repositories rather than
accessing the physical data source directly. And this clearly separates the
physical data access technologies and business logic technologies.
Following is an example of how to implement the employee
repository. Starting with the interface.
public interface IEmployeeRepo
{
void Add(Employee newEmp);
void Update(Employee emp);
void Remove(Employee emp);
IList<Employee> Search(Expression<Func<Employee, bool>> predicate);
Employee
GetById(int
empId);
}
Even though I have written the update method in this interface,
it is unlikely that in a real production system that we are having this kind of
individual update method. Mostly, we are using the
UOW design pattern for the
atomic updates in the repositories.
The Search function is also using a LINQ predicate in order
to enable the calling entity to use LINQ queries for search features.
Following is an example of how to use this Interface when we
need to dealt with the Employee entity.
public class WorkingClass
{
public void DoWork(IEmployeeRepo repository)
{
repository.Add(new Employee());
repository.Search(x => x.Name == "James");
repository.GetById(23);
}
}
We need to create these repositories for each and every
entity in the application. Which is leading to a maintenance problem. Hence it
is advisable to create Generic repository to handle operations rather than
create repositories for each and every entity.
Following is a Sample
Interface for a generic repository.
public interface IRepository<T>
where T : class, IEntity
{
IQueryable<T> FindAll();
IQueryable<T> Search(Expression<Func<T, bool>> predicate);
T GetById(int id);
void Add(T newEntity);
void Remove(T entity);
}
We are using the generic type T to represent entities in
repository.
Following is the concrete implementation of the IRepository.
public class RepositoryImpl<T> : IRepository<T>
where T : class, IEntity {
public RepositoryImpl(ObjectContext context) {
_objectSet = context.CreateObjectSet<T>();
}
public IQueryable<T> Search (Expression<Func<T, bool>> predicate) {
return _objectSet.Where(predicate);
}
public void Add(T newEntity) {
_objectSet.AddObject(newEntity);
}
public void Remove(T entity) {
_objectSet.DeleteObject(entity);
}
public IQueryable<T> FindAll()
{
return _objectSet;
}
public T GetById(int id)
{
return _objectSet.Single(x => x.Id == id);
}
protected ObjectSet<T> _objectSet;
}
You can see that the object context playing a big role when
creating the repository instance. This is the actual entity framework context
we are using here to connect to the database. We can see that how it is converted the EF
specific operations on objects based on the required method.
One thing to note in GetById method, it requires the attribute
Id contains on each and every entity that we are dealing with. This is achieved
using the IEntiry interface which make sure all the inherited entities consist
of id attribute.
public interface IEntity {
int Id { get; }
}
Following depicts how we can use the IRepository implementation
in a worker class. As an example, I am using a web controller class.
public class WorkerController : Controller
{
public WorkerController()
:this(new SqlUnitOfWork())
{
}
public WorkerController(IUnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
_repository = _unitOfWork.Employees;
}
public ViewResult Index()
{
var model = _repository.FindAll()
.OrderBy(e => e.dateRegistered);
return View(model);
}
public ViewResult Details(int id)
{
var model = _repository.FindById(id);
return View(model);
}
[HttpPost]
public ActionResult Edit(int id, FormCollection collection)
{
var model = _repository.FindById(id);
TryUpdateModel(model, new[] { "FirstName", "dateRegistered"
});
if (ModelState.IsValid)
{
_unitOfWork.Commit();
return RedirectToAction("Index");
}
return View(model);
}
private readonly IUnitOfWork _unitOfWork;
private readonly IRepository<Employee> _repository;
}
Ultimately , you can see that the controller class do not
need to bother about how this data been actually accessed by the respective repository.
This is the real power of this repository pattern.
