2

关于何时最好嵌套模型名称空间以及何时最好将它们全部保留在顶层的指导方针是什么？

例如，当我有几个类都与一个核心类有关（并且系统的大部分只处理该核心类）时，我的直觉告诉我这样声明它们：

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 等......

也许我还不够清楚，所以我会确保在要求澄清时更新它。

4

1 回答 1

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

因此，有很多方法可以完成您的需求，但没有一种方法建议您在实际上没有命名空间冲突时为应用程序的核心功能设置命名空间。考虑到您已经遇到的头疼问题，我认为您会更乐意将应用程序的核心模型留在顶级命名空间中，并且只嵌套实际存在冲突的替代模型。

于 2012-04-24T13:10:40.177 回答