Separation Of Concern And Data Access From Within Code

It is difficult to talk about application architecture without talking about the separation of concern (SoC).

Separation of concern (SoC) is a software development concept that separates an application or a software into different sections, or concerns, where each concern has a different purpose.

Example

The example below illustrates the concept of the separation of concern and each project in the solution explorer represents a concern or a section that can encapsulate information that can be developed and updated independently.

WebApp.Model - represents the data layer.
WebApp.Repository - represents the bridge of communication between the data layer and business logic layer.
WebApp.Template - represents business logic layer.

layer

In this article, I will talk about WebApp.Repository section and how it should be implemented to apply abstraction layer between the data access layer and the business logic layer.

Before starting the code and the explanation of each part let’s see a brief definition of a repository design pattern according to Exam Ref 70-486 book.

The primary data access pattern in C# is the Repository pattern, which is intended to create an abstraction layer between the data access layer and the business logic layer. This abstraction helps you handle any changes in either the business logic or the data access layer by breaking the dependencies between the two. It also enables the business logic layer to access the repository without knowing the specific type of data it is accessing, such as a Microsoft SharePoint list or a database. What the repository does internally is separate from the business logic layer.

Let’s jump into it and do more practice.

The first step is to create the necessary interfaces:

public interface IRepository < TEntity > where TEntity: class
{
TEntity GetById(int id);
IEnumerable < TEntity > GetAll();
void Add(TEntity tEntity);
void AddRange(IEnumerable < TEntity > tEntity);
void Remove(TEntity tEntity);
void AddRemove(IEnumerable < TEntity > tEntity);
}

IRepositoy interface is a generic interface where it passes any type of type “class” or i passes any type that is a reference type because the keyword “class” represents a reference type.

If you want to pass a value type you should replace “class” keyword with “struct”.

In this case, I will keep class keyword because I am going to deal with objects.

Also, notice that there are three sets of signature methods in IRepository interface.

Signature methods for retrieving, adding and removing objects.

public interface IProductRepository: IRepository < Product >
{
IEnumerable < Product > GetProductByManufactoryName(string manufactoryName);
}

IProductRepository interface implements the generic IRepository of type Product.

Also, IProductRepository interface will have the signatures of all your custom methods that treat anything related to a Product data.

Product - represents an entity.

If you have a different Entity Order then you should create a new interface IOrderRepository.

For example, public interface IOrderRepository: IRepository<Order> should have its own signatures methods that treat anything related to an Order data.

public interface IUnitOfWork: IDisposable
{
IProductRepository ProductRepository
{
get;
}
// IOrderRepository OrderRepository {get;}
int Save();
}

Unit of Work design pattern allows the coordination of multiple repositories by creating a single shared class for them all.

IUnitOfWork interface implements an IDisposable interface that contains Dispose method Also, I added “Save ()” that will do the persistence.

Second step is the implementation of the interfaces and get all the benefits:

public class Repository < TEntity > : IRepository < TEntity > where TEntity: class
{
protected readonly DbContext _dbContext;
public Repository(DbContext dbContext)
{
_dbContext = dbContext;
}
public void Add(TEntity tEntity)
{
_dbContext.Set < TEntity > ().Add(tEntity);
}
public void AddRange(IEnumerable < TEntity > tEntity)
{
_dbContext.Set < TEntity > ().AddRange(tEntity);
}
public IEnumerable < TEntity > GetAll()
{
return dbContext.Set < TEntity > ().ToList();
}
public TEntity GetById(int id)
{
return _dbContext.Set < TEntity > ().Find(id);
}
public void Remove(TEntity tEntity)
{
_dbContext.Set < TEntity > ().Remove(tEntity);
}
public void RemoveRange(IEnumerable < TEntity > tEntity)
{
_dbContext.Set < TEntity > ().RemoveRange(tEntity);
}
}

The generic class IRepository implements the generic IRepository interface to use all its defined methods.

DbContext is injected in Repository constructor.

_dbContext is marked as protected because it should be used in ProductRepository class. Also, notice that the DbContext class is a part of the Entity Framework and it comes from using System.Data.Entity.

public class ProductRepository: Repository < Product > , IProductRepository
{
public ProductRepository(NORTHWINDEntities dbcontext): base(dbcontext) {}
public NORTHWINDEntities GetData {
get
{
return _dbContext as NORTHWINDEntities;
}
}
public IEnumerable < Product > GetProductByManufactoryName(string manufactoryName)
{
return GetData.Products.ToList();
}
}

ProductRepository class implements IProductRepository to get the customized method

GetProductByManufactoryName

Notice that NORTHWINDEntities class comes from your Model (WebApp.Model concern) and it inherits from DbContext.

Here is the piece of code where your NORTHWINDEntities lives,

public partial class NORTHWINDEntities: DbContext
{
public NORTHWINDEntities(): base("name= NORTHWINDEntities ") {}
public virtual DbSet < Product > Products
{
get;
set;
}
}

UnitOfWork that contributes the work of all repositories,

public class UnitOfWork: IUnitOfWork
{
private readonly NORTHWINDEntities _dbContext;
public UnitOfWork(NORTHWINDEntities dbContext)
{
_dbContext = dbContext;
ProductRepository = new ProductRepository(_dbContext);
}
public IProductRepository ProductRepository
{
get;
}
public int Save()
{
return _dbContext.SaveChanges();
}
public void Dispose()
{
_dbContext.Dispose();
}
}

Finally, use of UnitOfWork to call your repository.

using WebApp.Model;
using WebApp.Repository.core;
using WebApp.Repository.repository;
Public class HomeController: Controller
{
private readonly IUnitOfWork _unitOfWork;
Public HomeController()
{
_unitOfWork = new UnitOfWork(new NORTHWNDEntities());
}
public async Task < ActionResult > Index()
{
// Search Product By ManufactoryName
Product product = _unitOfWork.Product.GetProductByManufactoryName("Ayoubation");
if (product != null)
{
ViewBag.myProduct = product.ProductName;
}
// Update product
product.ProductName = "Mercedes";
// Add new Product
Product myProduct = new Product
{
ProductName = "Celine disc",
Discontinued = true
};
_unitOfWork.Product.Add(myProduct);
_unitOfWork.Save();
// Search All
IEnumerable < Product > products = _unitOfWork.Product.GetAll();
_unitOfWork.Dispose();
return View(products);
}
}

That’s it. You have implemented the abstraction layer between the business logic and data access layer by applying the Soc.

1 Comment

Join the conversation! Your thoughts help the community grow.

Kramer Lee8y ago
Hi there, thank you so much for this helpful article. But for this line of code: Product product = _unitOfWork.Product.GetProductByManufactoryName("Ayoubation"); causes some exception. Because Product is an entity and it belongs to NORTHWNDEntities. So I dont think it works fine. Please tell me if I am wrong here! Thanks. And you should have reviewed all the ways of access to Product via _unitOfWork variable.