去仓库还是不去仓库

Question

当我第一次学习领域驱动设计时，我还被介绍给了存储库和工作模式单元，这些模式曾经似乎是那些把SQL查询(比如警告语言)抛到数据库上的酷孩子们的首选。我对这个话题越深入，就越了解到它们似乎不再必要了，因为像EF和NHibernate这样的ORM将工作单元和存储库都实现为一个API，称为会话或上下文。

现在我不知道该怎么办了。存储库或不存储库。我非常理解这样一种观点，即这种泄漏的抽象只会使事情变得过于复杂，而不会增加任何可能简化数据访问的内容，然而，将我的应用程序的每一个可能的方面都耦合到例如Entity Framework上是不对的。通常，我遵循一些简单的指导原则：

1. 域层是系统的核心，包含实体、服务、存储库.
2. 基础设施层提供与基础设施有关的域接口的实现，例如文件、数据库、协议。
3. 应用层拥有一个组合根，它将事物连接起来并编排所有内容。

我的解决方案通常如下所示：

Domain.Module1
Domain.Module2
    IModule2Repo
    IModule2Service
    Module2
Infrastructure.Persistence
    Repositories
        EntityFrameworkRepositoryBase
MyApp
    Boostrapper
        -> inject EntityFrameworkRepositoryBase into IRepository etc.

我通过使用IRepository<'T>来保持域层的清洁，这也是一个域关注点，而不依赖于告诉我如何访问数据的任何其他内容。当我现在要做一个需要数据访问的IModule2Service的具体实现时，我必须注入DbContext，并以此直接将其耦合到基础结构层。(在Visual项目中，由于循环依赖关系，这可能会变得非常棘手！)

Additionally，除了保存人和他妈的作品，还有什么可以替代的？CQRS？如何抽象一个纯粹的基础设施框架？

Answer 1

“保存”lol..。

无论如何，您不希望域耦合到EF，这就是为什么存储库接口中的T应该是域聚合根和而不是一个EF实体(或为正确地与EF一起工作而设计的“域”对象)。

域层从来不与持久性相耦合，因为它只知道抽象。当Module2Service需要数据访问时，它要么使用DAO (或者存储库--如果有意义的话，也不一定使用DDD版本)，要么使用DAL实现服务本身(如果它不包含业务逻辑)。

在您的例子中，最好的方法可能是DAO/存储库，它当然会“隐藏”EF部分。如果看起来您编写的代码太多了，那么您确实没有编写代码，我认为，与节省50 LoC (整个5-10分钟)相比，保持适当的关注点分离最为重要。

CQRS对于一个丰富的域来说总是个好主意，但是作为任何解决方案，它都需要更多的代码(我知道每个编码器在定义上都是懒惰的，但是我们需要做一个“该死的”工作，一个应用程序不构建自己，一个可维护的应用程序在一开始就是更多的工作)。如果抽象纯基础结构框架意味着隐藏EF，那么存储库是最好的选择，而且您甚至不必为类命名“存储库”，这是重要的原则，而这正是回购所做的:为域抽象持久性。