- 视图可以调用控制器
- 控制器仅与视图和服务层(事务所在的位置)对话
- 服务层有一系列对包装在事务中的域对象的调用
- 域对象包含对 dao 层的调用。
- dao 层填充域对象并保存数据。
但是我可以在不同的层传递域对象以通过 getter 访问数据,或者我是否必须使用 dto - 一个包含特定于视图/用例的数据的缩减域对象。在层周围传递域对象似乎鼓励打破层只能与指定的其他层对话的规则。但另一方面,这就是 DDD 的意义所在?如果最好从域对象中获取数据并放入 dto,那么控制器应该在哪里进行?
但是我可以在不同的层传递域对象以通过 getter 访问数据,或者我是否必须使用 dto - 一个包含特定于视图/用例的数据的缩减域对象。在层周围传递域对象似乎鼓励打破层只能与指定的其他层对话的规则。但另一方面,这就是 DDD 的意义所在?如果最好从域对象中获取数据并放入 dto,那么控制器应该在哪里进行?
就我个人而言,我总是使用视图模型(您的视图的 DTO)。这有助于减少传递给视图的数据量,并避免意外泄露安全数据。
从理论上讲,UI(或多个 UI 或 Web 服务)应该插入您的系统顶部。例如,如果您通过 Web 服务公开您的系统,您可能还希望以某种方式展平和减少数据,而不是创建对您的域实体的依赖(因此您可以在不破坏外部系统的情况下更改它们)并再次不要在您的域实体中公开任何 ID 或敏感数据。
我想这将适用于任何开发实践,而不仅仅是 DDD。
虽然在规范的分层架构中确实应该尽可能地划分事物,但将域实体一直传递到 UI 对我来说似乎是可以接受的,尤其是在表示层和域层位于同一层的简单应用程序中。它只需要 UI 具有对域的引用,这并不令人震惊(反过来实际上会出现问题)。
Mark Seemann 有一篇关于这个问题的有趣想法的博客文章,尽管我不同意他的所有观点。
您应该将域放在所有其他层旁边,因为它应该 100% 独立于其他所有层。因此你应该可以在任何地方使用它。
只有当两个或多个不同的根聚合需要交互时,才应使用 DDD 中的服务。
至于事务,为什么不直接用TransactionScope
在 UI 层呢?它仍然是持久性无知。
我个人直接在 UI 中使用存储库(因为 DDD 中的存储库是数据库抽象)