Rails 应用程序中的命名空间模型答案

【问题标题】：Namespacing models in a Rails applicationRails 应用程序中的命名空间模型
【发布时间】：2012-03-28 18:30:12
【问题描述】：

我最近和我的一个朋友进行了一次讨论，他也是一名 RoR 开发人员。我们讨论了应该如何管理 Rails 模型。就我个人而言，我喜欢在默认命名空间中只保留根模型（例如 User、Article、Bill 等），而依赖模型会转到具有根名称的模块（例如 User::Profile、User::Activity）它们关联的模型。

另一方面，我看到很多项目在默认命名空间中有大约 100 个模型，称为 user_profile、user_activity 等。从Java（Spring）的发展来看，java社区倾向于将类组织在包中，并按逻辑分组，我觉得这很吸引人。

所以问题是：在模块中对模型进行分组是否有任何缺点（除了关系定义中的额外 :class_name ）以及人们通常不这样做的任何具体原因吗？

【问题讨论】：

标签： ruby-on-rails rails-models

【解决方案1】：

虽然命名空间有其优势，但它确实需要在整个模型中添加异常。 Foo::Bar 假定表名称为 bars，同样bar_id 用于关联，而您可能更喜欢使用 foo_bars 和 foo_bar_id。

如果你真的对此有强烈的感觉，你可能想看看是否有一个插件可以为你解决这个问题，或者实现你自己的扩展。

我使用命名空间的唯一情况是用于第三方应用程序中的附加组件，我不想声明根级模型名称，因为那会很烦人。在这种情况下，额外的努力是值得的。

如果您对看到 100 多个没有任何分组的模型文件感到困扰，那么您可能会同样对看到没有分组的 100 多个表感到烦恼，这通常是您无法解决的问题。

控制器很自然地适合分组，但模型并不那么容易适应，至少不能使用现有的 ActiveRecord。

【讨论】：

我不记得上次打开数据库浏览器是什么时候了。使用 ruby 可以很自然地抽象出这些东西。据我记得，Foo::Bar 会生成一个“foo_bar”表。唯一的缺点是您必须在关联中指定 :class_name => Foo::Bar。我想知道如果 Rails 应用程序鼓励将所有模型保存在一个目录中，它应该如何处理复杂的应用程序。我的意思是，如果应用程序增长过多，命名空间是所需重构的一部分，还是只是切换到 Java？）
我通常采用使用前缀作为命名空间的方法，因此您可以创建 UserProfile 和 UserActivity 之类的东西，而不是 Profile 或 Activity。这导致列表中的自然分组。很少有一个具有 500 多个模型的应用程序会从命名空间中显着受益。复杂就是复杂。有时，诚实地告诉您您的应用程序有多么复杂，而不是试图通过掩饰复杂性并让查找内容变得更加困难来假装它实际上很简单。