I am learning Onion Architecture by Jeffrey Palermo for more than 2 weeks now. I have created a test project by following this tutorial. While studying I came across this question on SO. According to accepted answer, one person nwang
suggests that Methods like GetProductsByCategoryId should not be in Repository and one the other hand Dennis Traub
suggests that it is the responsibility of the Repository. What I am doing is :
I have a General Repository in Domain.Interface
in which I have a method Find
:
public interface IRepository<TEntity> where TEntity : class
{
IEnumerable<TEntity> Find(Expression<Func<TEntity, bool>> filter = null);
.......
.......
.......
}
Then I created a BaseRepository
in Infrastucture.Data
:
public class RepositoryBase<TEntity> : IRepository<TEntity> where TEntity : class
{
internal readonly DbSet<TEntity> dbSet;
public virtual IEnumerable<TEntity> Find(
Expression<Func<TEntity, bool>> filter = null)
{
IQueryable<TEntity> query = dbSet;
if (filter != null)
{
query = query.Where(filter);
}
return query.ToList();
}
}
And I have a concrete repository in Infrastructure.Data
public class ProductRepository : RepositoryBase<Product>, IProductRepository
{
public ProductRepository(MyDBContext context)
: base(context)
{
}
}
Now what I am doing in my Service Layer is Injecting Repository into Service and calling Repository.Find
for methods like GetProductsByCategoryId
. Like :
public class ProductService : IProductService
{
private readonly IUnitOfWork _unitOfWork;
private readonly IProductRepository _productRepository;
public ProductService(IUnitOfWork unitOfWork, IProductRepository productRepository)
{
_unitOfWork = unitOfWork;
_productRepository = productRepository;
}
public IList<Product> GetProductsByCategoryId(int CategoryId)
{
// At the moment, My code is like this:
return _productRepository.Find(e => e.CategoryId == CategoryId).ToList();
// My confusion is here. Am I doing it right or I need to take this code to
// ProductRepository and call _productRepositoy.GetProductsByCategoryId(CategoryId) here instead.
// If I do this, then Service Layer will become more of a wrapper around repository. Isn't it?
// My question is : What exactly will be the responsibility of the Service Layer in Onion Architecture?
}
}
Now we create the third layer of the onion architecture which is a service layer. To build this layer, we create one more class library project named OA. Service. This project holds interfaces and classes which have an implementation of interfaces. This layer is intended to build loosely coupled applications.
Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.
Clean Architecture was introduced by Robert “Uncle Bob” Martin in 2012 in this post. It builds on the concepts of Onion Architecture but with somewhat different details of the layers. Instead of “Domain Model”, it refers to the core as “Entities”, but still representing enterprise-wide business rules.
According to Jeffrey Palermo: "The overall philosophy of the Onion Architecture is to keep your business logic and model in the middle (Core) of your application and push your dependencies as far outward as possible.
The way you designed your application is ok... but only if your service will come to handle other things than just wrap up the repository methods!
Always keep in mind the YAGNI principle that says:
Always implement things when you actually need them, never when you just foresee that you need them
Let's say that you have a user story that says that whenever a product description is not found in your DB, you should retreive it from somewhere else (calling an external service or something). Then it seems obvious that your ProductService will have to have a
private readonly IProductRepository _productRepository;
but also a
private readonly IProductDescriptionService _productDescriptionService;
In that situation it really makes sense to add a service layer on top of your repositories.
I find that sometimes things can get over abstracted for the sake of it and offer no real value. I would say that the structure in your example is fine and follows the pattern correctly. Your service layer, correctly, is acting to serve the needs of the client UI, it is loosely coupled to the data layer and contains any business logic needed to manipulate the data.
I always think it is more productive to start simple and build upon your structure than it is to over abstract, over complicate and over bloat a project. A business or technical case will often drive the project, and dictate whether it is needed.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With