在外墙中引用存储库是否正确

Question

或者我应该总是通过服务方法获取我的实体吗？

由于

Answer 1

大多数时候我会尝试尽可能地分离我的图层。通常我会将我的服务作为业务逻辑的外观。在业务逻辑中，我使用像DI这样的DI容器来解析我的存储库......

示例：

IUnityContainer container = IoCManager.Container;
using (var repository = container.Resolve<IRepository<Token>>())
{
    return repository.Eagerly(f => f.Fetch<TokenSetting>(t => t.Settings))
                     .Where(t => t.Value == tokenGuid && t.Expired == null)
                     .FirstOrDefault();
}

我的业务逻辑现在在我的基础架构层（存储库）中不包含任何依赖项。有关一个很棒的Repository实现，请看一下NCommon。 Ritesh Rao写了一些关于DDD模式使用的很好的例子。

引用您的存储库是否错误是主观的。我认为DDD纯粹主义者会告诉你最有可能的。 “你想要实现多少SoC”才是真正的问题。通常最好通过松散耦合来争取高内聚力，但有时这可能是过度杀伤。

希望这有帮助。

---

<强> [EDITED]

存储库可以存在于域中。实际上，他们介于您的业务逻辑/模型和基础架构模型之间。依靠接口而不是实现是正确的。

看看马丁福勒的 - Separated Interface Pattern。在上面的例子中，我依赖于界面。 DI容器解析了我的具体存储库类的实际实现。这是我学习的一个DDD图，我一直在提炼。