Rails中的OO设计：在哪里放置东西 [英] OO Design in Rails: Where to put stuff

问题描述

我真的很喜欢Rails（即使我通常是RESTless的），我也很喜欢Ruby。尽管如此，创建大型ActiveRecord子类和大型控制器的趋势还是很自然的（即使您确实为每个资源使用一个控制器）。如果要创建更深的对象世界，您将把类（和我想的模块）放在哪里？我正在询问视图（在Helpers本身中），控制器和模型。

I'm really enjoying Rails (even though I'm generally RESTless), and I enjoy Ruby being very OO. Still, the tendency to make huge ActiveRecord subclasses and huge controllers is quite natural (even if you do use a controller per resource). If you were to create deeper object worlds, where would you put the classes (and modules, I suppose)? I'm asking about views (in the Helpers themselves?), controllers and models.

Lib没问题，我发现一些解决方案，可使其在开发环境中重新加载，但我想知道是否有更好的方法可以做到这一点东东。我真的只是担心班级过大。另外，引擎又如何呢？

Lib is okay, and I've found some solutions to get it to reload in a dev environment, but I'd like to know if there's a better way to do this stuff. I'm really just concerned about classes growing too large. Also, what about Engines and how do they fit in?

推荐答案

由于Rails提供了MVC结构，因此自然而然地结束了仅使用 为您提供的模型，视图和控制器容器。对于初学者（甚至是一些中级程序员）来说，典型的习惯用法是将应用程序中的所有逻辑塞入模型（数据库类），控制器或视图中。

Because Rails provides structure in terms of MVC, it's natural to end up using only the model, view, and controller containers that are provided for you. The typical idiom for beginners (and even some intermediate programmers) is to cram all logic in the app into the model (database class), controller, or view.

有人指出了胖模型，瘦控制器范例，中级开发人员匆忙从控制器中删除了所有内容并将其扔进模型，这开始成为应用逻辑的新垃圾桶。

At some point, someone points out the "fat-model, skinny-controller" paradigm, and intermediate developers hastily excise everything from their controllers and throw it into the model, which starts to become a new trash can for application logic.

瘦控制器实际上是一个好主意，但是必然的结果（将模型中的所有内容都放进去）并不是最好的计划。

Skinny controllers are, in fact, a good idea, but the corollary--putting everything in the model, isn't really the best plan.

在Ruby中，您有几个不错的选择，可以使事情更加模块化。一个比较流行的答案是只使用包含方法组的模块（通常藏在 lib 中），然后将模块包含在适当的类中。如果您有希望在多个类中重用的功能类别，但仍在功能上仍附加到这些类的情况下，这将很有帮助。

In Ruby, you have a couple of good options for making things more modular. A fairly popular answer is to just use modules (usually stashed in lib) that hold groups of methods, and then include the modules into the appropriate classes. This helps in cases where you have categories of functionality that you wish to reuse in multiple classes, but where the functionality is still notionally attached to the classes.

记住，当您在一个类中包含一个模块，这些方法成为该类的实例方法，因此您仍然最终得到一个包含 ton 方法的类，它们被很好地组织为多个文件。

Remember, when you include a module into a class, the methods become instance methods of the class, so you still end up with a class containing a ton of methods, they're just organized nicely into multiple files.

此解决方案在某些情况下可以很好地工作-在其他情况下，您将要考虑使用代码中不是的类模型，视图或控制器。

This solution can work well in some cases--in other cases, you're going to want to think about using classes in your code that are not models, views or controllers.

一种思考的好方法是单一责任原则，即一个类应该对单个（或少量）事物负责。您的模型负责将数据从应用程序持久存储到数据库中。您的控制器负责接收请求并返回可行的响应。

A good way to think about it is the "single responsibility principle," which says that a class should be responsible for a single (or small number) of things. Your models are responsible for persisting data from your application to the database. Your controllers are responsible for receiving a request and returning a viable response.

如果您的概念与这些框格不尽相同（持久性，请求/响应管理） ，您可能想考虑如何将建模为有问题的想法。您可以在应用程序/类或其他任何地方存储非模型类，并通过执行以下操作将该目录添加到加载路径：

If you have concepts that don't fit neatly into those boxes (persistence, request/response management), you probably want to think about how you would model the idea in question. You can store non-model classes in app/classes, or anywhere else, and add that directory to your load path by doing:

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

如果您使用的是乘客或JRuby，您可能还希望将路径添加到热切的加载路径中：

If you're using passenger or JRuby, you probably also want to add your path to the eager load paths:

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

底线是一旦到达Rails的某个位置，您就会发现自己在问这个问题，现在该增强您的Ruby知识并开始建模不仅仅是Rails默认为您提供的MVC类的类。

The bottom-line is that once you get to a point in Rails where you find yourself asking this question, it's time to beef up your Ruby chops and start modeling classes that aren't just the MVC classes that Rails gives you by default.

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

Update: This answer applies to Rails 2.x and higher.

这篇关于Rails中的OO设计：在哪里放置东西的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！