Rails中的命名空间模型：联合的状态是什么？
从一开始，Rails就遇到了命名空间模型的问题。 随着时间的推移，几乎所有人都放弃了使用它。 我自己包括在内。
随着Rails 2.3的推出，我想了解情况的最新情况。 我想到的具体问题是：
- 首先，去哪儿好？
- 表命名，遵循什么规则？
- 协会，如何以最少的冗长声明他们？ 如何命名外键列？
- 自动要求，如果将模型文件放在与命名空间匹配的子目录中，它是否有效？ 或者，如何命名以及放置文件的位置？
- 生成，模型生成器是否成功且正确地处理名称空间？
- 一代，脚手架发电机怎么样，包括控制器？
- 任何不兼容/怪异的人应该注意什么？
我在这个问题上看到的最好的写作来自Strictly Untyped 。 据我所知2.3还没有解决任何问题，这意味着它们仍然不可靠。
我们最近在公司内部对此进行了大讨论。 我想在最后，我们认为如果你不能在数据库中命名空间表，那么命名模型是没有意义的。 我们决定为模型添加前缀（User，UserAddress，UserEmailAddresses）并将它们放入users目录，然后使用：
config.load_paths << "#{RAILS_ROOT}/app/models/users" 加载模型。 为了控制模型中的详细程度，我们经常这样做：
has_many :addresses, :class_name => "UserAddress"
生成时，我们创建它就好像没有命名空间（脚本/生成模型UserAddress）然后手动将其复制到用户目录。
耸肩。 我想最后这一切真的给你的是一个更干净的目录结构，这对像我这样的VIM用户来说实际上更麻烦，但对TextMaters来说很好。
我仍然会远离它。 当你考虑到代码中的麻烦和简洁性和清晰度时，任何获得的东西（我不确定那些老实说的东西）肯定会丢失。
我的最新应用程序有87个资源，包括各地的管理function。 我认为没有必要使用命名空间，恕我直言。