我一直在阅读“SQL Antipatterns: Avoiding the Pitfalls of Database Programming”一书，尤其是关于魔术豆反模式的书。在它显示了一个使用域模型解耦活动记录的图表，并在 PHP 中有示例，但在 Rails 中没有，它将此称为域模型和视图/控制器之间的 HAS-A 聚合以及域模型和活动记录之间的 HAS-A 组合（I假设这是 UML 语言）。
在 Rails 中，使用模型方法使瘦控制器变成胖模型似乎很常见，这些方法可以操作其他关联的模型，以便在任何给定的控制器中只能使用一个模型。但是，我想知道在 Rails 中是否有一种包括完全解耦的做法？
也就是说，创建一个无表模型或其他类用作域模型，充当控制器和活动记录对象之间的层（这些对象又映射到表），以便控制器具有更好的隔离性并且不需要知道任何东西关于底层数据库及其结构。它还提供了摆脱不解释它们应用的应用程序要求的 CRUD 方法的选项，这是书中的另一个批评。
您可能会发现这个基于 Rails 的应用程序很有帮助：https ://github.com/qertoip/guru_watch - 它旨在展示如何以 Robert C. Martin 推荐的方式与 ActiveRecord 分离。它被称为用例驱动架构或实体-控制-边界模式。
我的评论来自于将 DDD 与 ASP.NET MVC 一起使用。将控制器绑定到域实体的推荐方法是通过视图模型，这是专门用于绑定到特定视图的DTO 。视图模型在绑定机制和域模型之间提供了一个非常需要的缓冲区。通常，给定视图可能是多个域实体甚至报告对象的组合，因此不直接与任何给定域实体对应。在视图模型中声明视图所需的属性使这些数据需求变得明确，并且不会导致人们尝试调整域模型以满足视图的需求。
当然，不利的一面是可能会出现双类层次结构，在这种层次结构中，您可能拥有一个与您的许多域实体相对应的视图模型。然而，在实践中，我发现维护双重类层次结构比担心更改域实体的后果要容易得多。看看再利用的谬误。
在 SOA 系统中，视图模型“包装”的对象可能不是域实体，而是代表那些域实体的 DTO。这不会违反视图模型的结构，因为它们本身就是 DTO，没有行为方面，只有数据。看看这篇讨论应用程序边界数据性质的文章。
为了回答您的问题，鉴于上述所有注意事项，我相信创建视图模型层对于 Rails 应用程序将是有利的。视图模型将填充来自活动记录对象或任何其他包含要呈现的数据的对象的数据，然后当用户输入数据时，视图模型将更新活动记录对象或域模型实体。虽然我会避免将此视图模型层称为域模型。