我们是否将Rails ActiveRecord用作混合结构,即数据结构+对象?

铁轨就是铁轨。还有什么可说的。是的,Rails中的一些习惯用法违反了良好的设计原则。但我们容忍这一点,因为这是铁路。

尽管如此,在大多数Rails应用程序中有太多的模型使用。我经常看到视图代码直接访问模型。我看到业务规则被折叠到活动的记录对象中。更好的方法是将业务规则与活动记录隔离,并将视图与模型隔离。这不会违反任何Rails习惯,并且会使Rails应用程序更加灵活和可维护。

如果你遵循Puristor方法太多,那么你就像Java一样陷入混乱,在那里它使用了所有正确的设计模式,但是没有人能记住你需要的八行代码,只需要打开一个文件并读取它的内容。

Rails的ActiveRecord框架是Martin Fowler的一个实现 Active Record design pattern . Rails中的活动记录肯定不仅仅是愚蠢的数据结构或DTO,因为它们具有行为:它们执行验证,它们可以告诉您它们的属性是否发生了变化等等,您是自由的,而且确实 encouraged ,在其中添加您自己的业务逻辑。

Rails通常鼓励良好的实践,例如MVC和语法醋,以使做坏事变得困难和/或难看。

是的,ActiveRecord故意破坏了封装。这不是对Rails的限制,而是对它所基于的模式的限制。Martin Fowler的ActiveRecord定义几乎与Rails使用的模板相同,他在 POEAA :

另一个反对的论点 主动的 记录 事实上它是夫妻 数据库的对象设计 设计。这就更难了 将设计重构为项目 前进。

这是一个 common criticism 其他框架的轨道。福勒自己说,ActiveRecord主要用于

…对于域逻辑来说 复杂……如果您的业务逻辑是 很复杂,你很快就会想用你的 对象的直接关系, 收藏、继承等等。 这些不容易映射到活动记录上。

福勒接着说,对于具有复杂域逻辑的更严重的应用程序, Data Mapper pattern 更好的方法是分离层。这就是Rails upcoming move to Merb 通常被视为Rails的积极举措,因为Merb除了使用ActiveRecord外,还使用了DataMapper模式。

我不确定德米特是ActiveRecord的主要关注点。相反,我认为破坏数据层和域层之间的封装会破坏Bob叔叔的 Single Responsibility Principle . 德米特,我认为是一个更具体的例子,如何遵循开放/封闭原则。但我认为所有这些背后的更广泛的想法是相同的:类应该做一件事,并对未来的变化保持健壮,而在某种程度上,ActiveRecord并不是这样的。

关于“德米特定律”,我没有提到距离的概念。我的意思是,“物体有多紧密的联系?”我的观点是,无论我是否愿意遵守“德米特定律”,这都会有所不同。

在ActiveRecord的情况下,涉及大多数LOD冲突的对象都被不可分割地绑定在一起,形成了密切的关系。更改这些对象的内部数据结构需要更改数据库以反映新结构。数据库的表通常“绑定”到单个数据库中,甚至通过外键约束(或至少包含主键和外键)反映这些“关联”。

因此,我一般不关心在我的AR对象之间跟踪LOD。我知道,由于它们的本质,它们彼此之间是紧密相连的。

另一方面,我会更关注更遥远物体之间的LOD,尤其是那些跨越MVC边界的物体或任何其他此类设计设备。