Rails 域模型对 Activerecord 的解耦答案

【问题标题】：Rails Domain model decoupling of ActiverecordRails 域模型对 Activerecord 的解耦
【发布时间】：2011-10-12 20:52:02
【问题描述】：

我一直在阅读“SQL 反模式：避免数据库编程的陷阱”一书，尤其是关于魔术豆反模式的书。在它显示了一个使用域模型解耦活动记录的图表，并在 PHP 中有示例，但在 Rails 中没有，它将此称为域模型和视图/控制器之间的 HAS-A 聚合以及域模型和活动记录之间的 HAS-A 组合（I假设这是 UML 语言）。

在 Rails 中，使用模型方法使瘦控制器变成胖模型似乎很常见，这些方法可以操作其他关联的模型，以便在任何给定的控制器中只能使用一个模型。但是，我想知道在 Rails 中是否有一种包括完全解耦的做法？

也就是说，创建一个无表模型或其他类用作域模型，充当控制器和 activerecord 对象之间的层（这些对象又映射到表），以便控制器具有更好的隔离性并且不需要了解有关基础数据库及其结构的任何信息。它还提供了摆脱不解释应用程序要求的 CRUD 方法的选项，这是书中的另一个批评。

【问题讨论】：

标签： ruby-on-rails activerecord domain-driven-design anti-patterns domain-model

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

当然，不利的一面是可能会出现双类层次结构，在这种层次结构中，您可能有一个与您的许多域实体相对应的视图模型。然而，在实践中，我发现维护双重类层次结构比担心更改域实体的后果要容易得多。看看The Fallacy of ReUse。

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

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

【讨论】：

感谢这为我指明了这个 stackoverflow 线程 stackoverflow.com/questions/2521522/… 的方向，然后是 Jay Fields，他在 RailsConfEU 07 上展示的演示者模式上做了一些工作blog.jayfields.com/2007/09/…
... 我认为这是在演示者模式或将相关的创作和其他逻辑转移到模型之间的折腾 Jamis Bucks 旋转瘦控制器胖模型，这似乎是 rails 世界的规范.我实际上更喜欢演示者模式，我认为它可以产生更清晰的代码。我还发现有一本书“Advanced Rails Recipes”包含演示者模式的 Jay Fields 实现，我会看看是否可以从图书馆找到并借用副本。我希望有人根据这项工作扩展了 Rails 生成器。