ruby-on-rails - Rails 中的 OO 设计 : Where to put stuff

Question

我真的很喜欢 Rails(尽管我通常不太喜欢 RESTless)，而且我喜欢 Ruby 非常面向对象。尽管如此，创建庞大的 ActiveRecord 子类和庞大的 Controller 的趋势是很自然的(即使您确实为每个资源使用了一个 Controller )。如果你要创建更深层次的对象世界，你会将类(和模块，我想)放在哪里？我问的是 View (在助手本身中？)、 Controller 和模型。

lib 没问题，我找到了some solutions to get it to reload in a dev environment ，但我想知道是否有更好的方法来做这些事情。我真的只是担心类(class)变得太大。另外，引擎怎么样？它们是如何适应的？

Answer 1

因为 Rails 根据 MVC 提供结构，所以最终仅使用为您提供的模型、 View 和 Controller 容器是很自然的。初学者(甚至一些中级程序员)的典型习惯是将应用程序中的所有逻辑塞进模型(数据库类)、 Controller 或 View 中。

在某些时候，有人指出了“胖模型，瘦 Controller ”范式，中级开发人员匆忙从他们的 Controller 中删除所有内容并将其扔到模型中，模型开始成为应用程序逻辑的新垃圾桶。

事实上，瘦 Controller 是个好主意，但推论——将所有内容都放入模型中并不是最好的计划。

在 Ruby 中，您有几个很好的选择可以使事情更加模块化。一个相当流行的答案是只使用包含方法组的模块(通常隐藏在 lib 中)，然后将模块包含到适当的类中。如果您有希望在多个类中重用的功能类别，但功能在概念上仍附加到类，这会有所帮助。

请记住，当您将一个模块包含到一个类中时，这些方法将成为该类的实例方法，因此您最终仍然会得到一个包含吨 方法的类，它们只是组织得很好分成多个文件。

此解决方案在某些情况下可以很好地工作——在其他情况下，您将要考虑在您的代码中使用不是模型、 View 或 Controller 的类。

考虑它的一个好方法是“单一职责原则”，它表示一个类应该负责单一(或少量)事物。您的模型负责将数据从您的应用程序保存到数据库。您的 Controller 负责接收请求并返回可行的响应。

如果您的概念不能完全符合这些框(持久性、请求/响应管理)，您可能需要考虑如何对所讨论的想法进行建模。您可以将非模型类存储在 app/classes 或其他任何地方，并通过执行以下操作将该目录添加到您的加载路径:

config.load_paths << File.join(Rails.root, "app", "classes")

如果您使用的是 passenger 或 JRuby，您可能还想将您的路径添加到预加载路径中:

config.eager_load_paths << File.join(Rails.root, "app", "classes")

底线是，一旦您在 Rails 中发现自己会问这个问题，是时候加强您的 Ruby 技能并开始建模类，而不仅仅是 Rails 为您提供的 MVC 类默认。

更新:此答案适用于 Rails 2.x 及更高版本。