entity-framework - DDD中的非业务逻辑数据库访问

Question

刚从 DDD 开始。我了解所有域实体及其逻辑应与存储库接口一起保存在域层中。在我的应用程序中，我将一些数据存储在数据库中，这些数据用于在运行时构建部分用户界面（表示层）。我应该在哪里保留此类类型的 poco 类和存储库接口，在应用程序层或域层中。我无法弄清楚，因为这些对象不会有任何与域相关的业务逻辑，但它们需要从数据库中获取水分，而且我使用的是 EF，所以对于数据访问，我需要实体和存储库，所以对我来说，显而易见的选择是保留它们域层中的所有其他实体和存储库接口，但违反了 DDD 规则

Answer 1

我想你已经回答了你自己的问题：

在我的应用程序中，我将一些数据存储在数据库中，这些数据用于在运行时构建用户界面（表示层）的一部分。

对用于服务 UI 的数据的访问应封装在表示层中。这与应用层的不同之处在于，DDD 应用层通过编排存储库并委托给适当的实体、域服务来实现用例——它围绕您的域层形成一个 API。不同的表示实现可以使用相同的应用服务。

然而，不同的表示层实现可能需要不同的数据。因此，将表示数据访问直接放在表示层中。这可以通过 EF 来实现，这不是 DDD 场景独有的。

Answer 2

考虑它的一个好方法是 - 如果出于性能原因必须用存储过程替换 EF，则不必修改域代码。所以任何需要隐藏在界面后面并可以替换的东西。

存储库可以是域逻辑的一部分。然而，不应该是持久性的机制。这可以很容易地封装到 DAL 服务或其他对象中，当然这些对象被编程为 IDALService 接口。因此，当您需要切换持久性（例如，从 EF 迁移到 NoSQL 解决方案）时，您只需编写一个实现 IDALService 接口的替代版本，就可以了。存储库仍然可以在其中执行逻辑，但现在使用一种新的方式来存储它们（这是控制反转的想法）。

至于 POCO 对象，在 DDD 中真正的问题是它们代表什么？它们是需要持久化的实体吗？他们是有价值的对象吗？不要让技术 (EF) 决定您的对象模型的结构是什么，而是提供转换为应用程序范围的方法。

Answer 3

在应用层。保持域完整和隔离。