Service Layer are repeating my Repositories

I'm developing an application using asp.net mvc, NHibernate and DDD. I have a service layer that are used by controllers of my application. E开发者_开发知识库verything are using Unity to inject dependencies (ISessionFactory in repositories, repositories in services and services in controllers) and works fine.

But, it's very common I need a method in service to get only object in my repository, like this (in service class):

public class ProductService {

   private readonly IUnitOfWork _uow;
   private readonly IProductRepository _productRepository;

   public ProductService(IUnitOfWork unitOfWork, IProductRepository productRepository) {
      this._uow = unitOfWork;
      this._productRepository = productRepository;
   }

   /* this method should be exists in DDD ??? It's very common */
   public Domain.Product Get(long key) {
      return _productRepository.Get(key);
   }

   /* other common method... is correct by DDD ? */
   public bool Delete(long key) {
      usign (var tx = _uow.BeginTransaction()) {
         try 
         {
           _productRepository.Delete(key);
           tx.Commit();
           return true;
         } catch {
           tx.RollBack();
           return false;
         }        
      }
   }

   /* ... others methods ... */

}

This code is correct by DDD ? For each Service class I have a Repository, and for each service class need I do a method "Get" for an entity ?

Thanks guys

Cheers

---

Your ProductService doesn't look like it followed Domain-Driven Design principles. If I understand it correctly, it is a part of Application layer between Presentation and Domain. If so, the methods on ProductService should have business meaning with regard to products.

Let's talk about deleting products. Is it as simple as executing delete on the database (NHibernate, or whatever?) I think it is not. What about orders which reference the to-be-deleted product? And so on and so forth. Btw, Udi Dahan wrote a great article on deleting entities.

Bottom line is, if your application is so simple that services do really replicate your repositories and contain only CRUD operations, you probably shouldn't do DDD, throw away your repositories and let services operate on entities (which would be simple data containers in that case).

On the other hand, if there is a complicated behavior (like the one with handling 'deleted' products), there is a point in going DDD path and I strongly advocate doing so.

PS. Despite which approach (DDD or not) you will eventually take I would encourage you to use some Aspect Oriented Programming to handle transaction and exception related stuff. You would end up with way to many methods such as DeleteProduct with same TX and exception handling code.

---

That looks correct from my perspective. I really didn't like repeating service and repository method names over and over in my asp.net MVC project, so I went for a generic repository approach/pattern. This means that I really only need one or two Get() methods in my repository to retrieve my objects. This is possible for me because I am using Entity Framework and I just have my repository's get() method return a IQueryable. Then I can just do the following:

Product product = from p in _productRepository.Get() where p.Id == Id select p; 

You can probably replicate this in NHibernate with linq -> NHibernate.

---

Edit: This works for DDD because this still allows me to interchange my DAL/repositories as long as the data library I am using (Nhibernate, EF, etc..) supports IQueryable.

I am not sure how to do a generic repository without IQueryable, but you might be able to use delegates/lambda functions to incorporate it.

---

Edit2: And just in case I didn't answer your question correctly, if you are asking if you are supposed to call your repository's Get() method from the service then yes, that is the correct DDD design as well. The reason is that the service layer is supposed to handle all your business logic, so it decides exactly how and what data to retrieve (for example, do you want it in alphabetical order, unordered, etc...). It also means that it can perform validation after loading if needed or validation before deleting and/or saving.

This means that the service layer doesn't care exactly how that data is stored and retrieved, it only decides what data is stored and retrieved. It then calls on the repository to handle the request correctly and retrieve/store the data in the way the service layer tells it to. Thus you have correct separation of concerns.