服务层正在重复我的存储库

Fel*_*ani 2 nhibernate asp.net-mvc service domain-driven-design repository

我正在使用asp.net mvc,NHibernate和DDD开发一个应用程序.我有一个服务层,由我的应用程序的控制器使用.一切都在使用Unity来注入依赖项(存储库中的ISessionFactory,控制器中的服务和服务中的存储库)并且工作正常.

但是,我需要一个服务方法来获取我的存储库中的对象,这是非常常见的(在服务类中):

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 ... */

}
Run Code Online (Sandbox Code Playgroud)

这个代码是DDD正确的吗?对于每个Service类,我都有一个Repository,对于每个服务类,我需要为一个实体做一个"Get"方法吗?

多谢你们

干杯

Szy*_*ega 9

您的ProductService看起来不像是遵循域驱动设计原则.如果我理解正确,它是Presentation和Domain之间Application层的一部分.如果是这样,ProductService上的方法应该具有与产品相关的商业含义.

我们来谈谈删除产品.它就像在数据库上执行删除一样简单(NHibernate,还是其他什么?)我认为不是.那些参考待删除产品的订单怎么样?等等等等.顺便说一句,Udi Dahan撰写了一篇关于删除实体的精彩文章.

最重要的是,如果您的应用程序如此简单以至于服务确实复制了您的存储库并且仅包含CRUD操作,那么您可能不应该执行DDD,丢弃您的存储库并让服务对实体进行操作(这将是简单的数据容器)案件).

另一方面,如果存在复杂的行为(比如处理'删除'产品的行为),那么DDD路径就有了一点,我强烈主张这样做.

PS.尽管采用哪种方法(DDD与否),我最终会鼓励您使用一些面向方面编程来处理与事务和异常相关的事情.最终会遇到许多方法,例如具有相同TX和异常处理代码的DeleteProduct.