关于何时更好地嵌套模型名称空间以及什么时候最好将它们保留为顶级？有什么指导？
例如，当我有几个类都与一个核心类有关（并且系统的大部分只处理那个核心类）时，我的直觉告诉我将它们声明为：
CoreModel
CoreModel::DependentOne
CoreModel::AnotherDependent
几乎总是这对应于has_many / belongs_to关系（我几乎认为这是约定优于配置的下一个候选者。）
而且，我的路线经常反映这种嵌套： / CoreModels /：core_model_id / DependentOne /：ID
我觉得我应该这样做的原因是因为同一大型应用程序的两个组件区域通常需要一个支持组件，其名称与软件的其他区域相同，但名称相同。我觉得名称间隔这些依赖模型（仅存在以支持核心模型）是最好的方法。
我很困惑，因为虽然有时候这样做可以让事情变得更容易（例如link_to只需要采用DependentOne模型并且会自动正确路由）但是其他项目如form_for拒绝正常工作（因为它没有正确路由，如果我将CoreModel添加到form_for它抱怨没有这样的路由core_model_core_model_dependent_one等....
也许我还不够清楚，所以我会确保随着请求澄清而更新。
答案 0 :(得分：2)
...the majority of the system only deals with that core class...
在这种情况下，我不会打扰他们的名字。
The reason I feel like I should do this is because often two component areas of the same large application may need a supporting component with similar if not identical names as other areas of the software. I feel like name spacing these dependent models (which only exist to support that core model) is the best way to go.
Bingo - 如果您有名称冲突，命名空间是修复它的好方法。但是，你有这个问题吗？
命名空间可以防止名称冲突，但在Rails中它还会引入一些陷阱和头痛以及（在整个应用程序中）更多的输入。所以，对我来说，除非你真的有名字冲突，否则它是不值得的。
考虑这样的结构，你的核心模型和许多只是帮助它的结构。
#Core Models
Model
Supporter
Assister
Helper
Benefactor
在应用的大部分时间里，您可能永远不会遇到问题。如果你最终击中一个，你可以这样做：
AltModel
AltModel::Supporter
OtherModel
OtherModel::Benefactor
或者如果它真的很简单，只需在类名前加上：
AltModelSupporter
OtherModelBenefactor
就此而言，以这种方式命名核心模型可能比“正确”命名它们更简单：
CoreModel
CoreSupporter
CoreAssister
因此，有很多方法可以实现您的需求，但没有一种方法可以让您在实际上没有命名空间冲突时，应该为应用程序的核心功能命名。考虑到您已经遇到的麻烦，我认为您将更高兴地将应用程序的核心模型留在顶级命名空间中，并且只能嵌套实际存在冲突的替代模型。