对服务层依赖项的建议答案

【问题标题】：Recommendations for dependencies in Service Layer对服务层依赖项的建议
【发布时间】：2014-04-20 01:19:31
【问题描述】：

在服务类中定义依赖关系的推荐架构方法是什么？

这样可以吗，当另一个类时，例如。 OrderService 依赖于存储库类 ex。 CartRepository 而不是 CartService？我是否应该始终为每个域对象创建一个存储库和一项服务？

public class CartService : ICartService
{
    private IBuyerRepository _buyerRepository;
    private ICartRepository _cartRepository;
    private IConfigService _configService;  
    private ISimpleDataService _simpleDataService;

    public CartService(IBuyerRepository buyerRepository,
                       ICartRepository cartRepository,
                       IConfigService configService)
    {
        _buyerRepository = buyerRepository;
        _cartRepository = cartRepository;
        _configService = configService;
    }

    public void Save(Cart cart)
    {
        _cartRepository.Save(cart); 
    }
}

OrderService文件：

public class OrderService : IOrderService
{
    public OrderService(ICartRepository cartRepository)
    {

    }
}

【问题讨论】：

域服务用于协调存储库和域对象之间的交互。我不会说在一个域服务中使用多个依赖项是个问题。
是的，我知道。我在问是否所有服务层类都应该依赖于另一个域对象服务类而不是存储库类。在这个例子中，OrderService 对 cartRepository 有依赖，但是如果我把这个依赖放在 ICarService 接口那里会不会更好？
不知道有没有这方面的明确规定。我认为在您的订单服务中使用购物车存储库没有任何问题。否则，您可能会使用仅在其他服务中使用的方法来弄乱您的 ICarService。
但是如果我想在数据库中每个保存对象之前检查一些验证逻辑（存在于服务类中），那么更好的方法可能是在 OrderService 类中注入服务类？

标签： c# architecture domain-driven-design

【解决方案1】：

作为第一步，您的实现很好，并且在一个简单但不太大的域中。

这样的实现具有以下优点：虽然每个 http resquest 只需一项服务来管理它需要的所有存储库，但管理 sql 事务以保持完整性并不困难。

它有太多的缺点：您可以编写两次或多次相同的业务规则……我们都很懒惰，所以这是个问题。但是，当某人或您在 6 个月后在其服务实现中第三次调用存储库并且忘记了业务规则时，就会发生重大故障......再见可爱的域......

我的建议是服务只调用它的存储库，并在需要时调用封装自己逻辑的其他服务。唯一要记住的技巧是传播交易以避免发生奇怪的事情。

希望对你有帮助，朱利安

【讨论】：