Rails：模型依赖类位置的最佳实践？

发布于 2024-07-13 02:01:27 字数 266 浏览 6 评论 0 原文

我有一个 Rails 应用程序运行得相当好，但事实上，我自己做这件事意味着一些可怜的草皮最终会看到这个并说，“你到底在想什么？你为什么把这个放在这里？！？！”

那个可怜的、遗憾的灵魂在哪里会期望看到一系列除了单个模型类之外什么都没有使用的类呢？显然，我可以将它与 TheModel 类一起放入 the_model.rb 中，但这可能会超出计划的两个类...

我考虑过 lib，但它不需要扰乱每个人的世界观...

谢谢你。

我的前任谢谢你。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

意中人 2024-07-20 02:01:27

将它们保留在 the_model.rb 中，直到您在多个地方需要它们为止。如果您进行不必要的重构，那么您就没有做可能有效的最简单的事情。你不会需要它。

此时，一般模式是为“问题”创建一个目录。请参阅 Jamis Buck 撰写的这篇博客文章或 Peter Marklund 的这篇文章了解更多信息。

回复收藏 0 原文

白龙吟 2024-07-20 02:01:27

一般来说：将类名转换为文件系统位置时遵循 Rails 命名约定。（即：将 FooHelper::Bar 类保留在 foo_helper/bar.rb 中）

您可以对仅使用一次的小帮助器类进行例外处理，并将它们保留在与您的模型相同的文件，但这些应该是例外。（但反之亦然，不要创建一行数千个单行文件）

使用模块和类命名空间对您有利。如果您有一个仅由模型使用（并依赖于）模型的帮助器类，请将它们放入模型类的命名空间中：

class TheModel::HelperClass
end

文件系统中的位置将为 app/models/the_model/helper_class.rb< /code>

不依赖于你的模型的东西可能仍然可以

module Bar
  class Foo
  end
end

在 bar/foo.rb 中命名，当然

你不应该害怕将不是模型的东西放入 >lib——这就是这个目录的用途

我想说关注点虽然很有用，但实际上并不是正确的方法，因为这是一种将单个类拆分为多个文件的方法，而您不需要似乎没有这样做。

In general: follow the Rails naming conventions when translating class names into filesystem locations. (that is: keep the class FooHelper::Bar in foo_helper/bar.rb)

You can make exceptions for small helper classes that are only used once and keep them in the same file as your model, but those should be exceptions. (but the converse is also true, don't create one-line thousands of single line files)

Use modules and class namespaces to your advantage. If you have a helper class that is only used by (and dependent on) your model, put them into the namespace of the model class:

class TheModel::HelperClass
end

the location in the file system would be app/models/the_model/helper_class.rb

And something that is not dependent on your model can probably still be namespaced

module Bar
  class Foo
  end
end

living in bar/foo.rb, of course

You should probably not be afraid to put things that are not models into lib -- that's what this directory is for

I'd say concerns, while useful, are not really the right way to go because that is a way to split a single class into multiple files and you don't seem to be doing that.