Rails Activerecord的域模型解耦

Question

我一直在读"SQL反模式:避免数据库编程的陷阱"一书,特别是围绕魔豆反模式.其中显示了使用域模型解耦activerecords的图表,并且在PHP中有示例,但不是Rails,它将此称为域模型和视图/控制器之间的HAS-A聚合以及域模型和activerecords之间的HAS-A组合(I假设这是UML说话).

在Rails中,通过使用模型方法来制作瘦控制器胖模型似乎很常见,这些方法可能会操纵其他相关模型,因此在任何给定的控制器中只能使用一个模型.但是,我想知道是否有一种练习包括Rails中的完全解耦？

也就是说,创建一个无表格模型或其他类作为域模型,充当控制器和activerecord对象之间的层(反过来又映射到表),这样控制器可以更好地隔离,不需要知道任何东西关于底层数据库及其结构.它还提供了远离CRUD方法的选项,这些方法无法解释它们适用的应用程序要求,这是书中的另一个批评.

Answer 1

您可能会发现这个基于Rails的应用程序很有帮助:https://github.com/qertoip/guru_watch - 它旨在展示如何以Robert C. Martin推荐的方式与ActiveRecord分离.它被称为用例驱动架构或实体控制边界模式.

Answer 2

我的评论来自于将 DDD 与 ASP.NET MVC 结合使用。将控制器绑定到域实体的推荐方法是通过视图模型，它们是专门用于绑定到特定视图的DTO 。视图模型在绑定机制和域模型之间提供了急需的缓冲区。通常，给定视图可能是多个域实体甚至报告对象的组合，因此不直接与任何给定域实体相对应。在视图模型中声明视图所需的属性可以使这些数据需求变得明确，并且不会导致人们尝试调整域模型来满足视图的需求。

当然，缺点是可能出现双类层次结构，其中您可能有一个与许多域实体相对应的视图模型。然而在实践中，我发现维护双类层次结构比担心更改域实体的后果要容易得多。看看重用的谬误。

在 SOA 系统中，查看模型“包装”的对象可能不是域实体，而是代表这些域实体的 DTO。这并不违反视图模型的结构，因为它们本身就是 DTO，没有行为方面，只有数据。看一下这篇文章，其中讨论了应用程序边界数据的性质。

为了回答你的问题，考虑到上述所有注意事项，我相信创建视图模型层对于 Rails 应用程序是有利的。视图模型将填充来自活动记录对象或包含要呈现的数据的任何其他对象的数据，然后当用户输入数据时，视图模型将更新活动记录对象或域模型实体。尽管我会避免将此视图模型层称为域模型。