我有几个从控制器调用的方法，感觉应该将它们拉出并放入控制器外部的可重用类中。人们通常把这些东西放在哪里？我知道我可以将它们放入我的 ApplicationController，但如果我认为以后可以在其他应用程序中使用这些方法，这似乎不是一个很好的解决方案。
另外，我的控制器中有一堆实用方法，可能不会在其他控制器中使用，或者将来根本不会使用，但我觉得它们只是让我的控制器有点膨胀。人们通常是为了清洁而将它们移到某个地方，还是最终得到一个巨大的控制器？
我来自 Java 和 Actionscript，我只是为这些东西创建新的 util 类。
【问题讨论】：
标签： ruby-on-rails ruby architecture
在lib目录下创建模块文件：
module ControllerUtil
def foo
end
def bar
end
end
在控制器中包含模块：
class UsersController < ApplicationController
include ControllerUtil
end
【讨论】：
与 Sahil kalra 2014 年的上述回答相关：
Rails 现在有一个app/controllers/concerns 目录，您可以在其中放置充满帮助方法的模块，并轻松地在控制器中包含或扩展它们。我只是从 application_controller 中复制并粘贴了所有逻辑密集型方法，它们开箱即用。
（当然，在将任何东西投入生产之前，您仍然应该确保一切正常。）
【讨论】：
lib 目录是您可以放置模块/类的地方，这些模块/类可以混入控制器或供控制器使用（以及其他任何东西，真的）。这可以是一个放置不属于其他领域的代码的地方（但要小心确保 lib 本身不会变成一团糟）。只是要记住的侧面 cmets：
如果您知道自己有大量相关功能可以或将用于其他应用程序，那么这可能是一个插件。
还值得牢记的是，创建一个不是 Active Record 对象的模型并没有错。再说一次，这取决于你所拥有的，这也可能是有道理的。
【讨论】：
lib 用于“通用库”逻辑，而不是域逻辑。因此，如果您有一些特定于该应用程序但对多个控制器通用的逻辑，那么正确的位置可能只是在 app/controllers 目录中的单独模块中。
控制器应该非常少 - 基本上是吸收参数并做出一些非常高级的决策。如果您有一些辅助函数正在做这些事情但不会被重用，那么将它们保留在控制器中是正确的做法。只需确保将它们标记为私有即可。
对于更常见的共享内容，您可以将它们返回到您的 ApplicationController（如果它们在所有控制器中使用）或返回到您的 app/models 目录中的类。我推荐模型目录而不是 lib，因为 Rails 在开发模式下更好地发现对这些文件的更改并重新加载它们。更改 /lib 中的文件往往需要重新启动网络服务器，这会减慢您的开发工作。这是不幸的，因为控制器助手真的不应该与模型混合。
不过，一般来说，如果您有多个这样的助手，您可能在控制器中做的太多了。仔细看看它们，看看它们中的一些是否不应该成为你的模型的一部分。
【讨论】：
您可以创建app/modules 目录，并在其中创建 XYZUtils 模块，例如
module XYZUtils
def abc
end
def efg
end
end
并在需要时将模块包含在控制器或模型等中。
include XYZUtils
您可以为与不同模型或实体相关的实用功能创建不同的模块
我不会喜欢/lib 目录，因为它应该包含项目相关的代码，而不是应用相关的，例如任务等。
我会将所有与 App 相关的代码保留在 /app 目录本身中
【讨论】：