我应该在哪里放置模型访问的功能？ - Rails 3.1

Question

我被告知帮助程序仅用于视图所需的功能。

我应该在哪里放入模特常用的功能？控制器怎么样？

放置常用函数的惯例是什么：

1）模型

2）观点

3）控制器

问题：在lib中创建一个模块来保存函数并将模块包含在类中会为类创建实例方法的加载。

问题：这三种常见且需要的功能怎么样？

Answer 1

  

问题：在lib中创建一个模块来保存函数并将模块包含在类中会为类创建实例方法的加载。

首先组织，然后优化

  

问题：这三种常见且需要的功能如何？   你真的有三种方法都需要的方法而且还不存在吗？   如果是，可能是你可以给出一个例子

我认为问题应该放在一般逻辑的位置。 你应该先考虑一下你的方法在考虑放置它之前的作用。 但无论你创造什么，当它变得越来越大或有价值时，你应该考虑将它作为一个宝石/插件出口。

内部导航逻辑（显示内容以及操作后的去向）：控制器

• App导航逻辑; application_controller
• 应用逻辑的子集;使用主控制器创建名称空间，类API_controller＆lt; application_controller

数据逻辑（如何操作，处理数据）：模型

• 数据;模型类方法（搜索，排序，计数，宏程序......）
• 基准;模型实例方法（修改，微处理......）

数据表示逻辑（如何显示数据）：助手，部分和装饰器

• 在我看来，Helper不是为此设计的。
• 特定数据的部分句柄布局。
• 申请装饰;处理通用数据表示帮助
• scope_decoration;你可以使用继承

布局语言逻辑（布局语言帮助）：助手

• 特定于您的应用; application_helper
• 特定于模型......; model_helper，但你应该考虑装饰者
• 通用;将它导出为宝石（超级形式助手，模板系统......）

布局逻辑（我应该显示此菜单吗？）：？

• 帮助者/装饰者/模型可以回答这个问题：@ user.can_edit？（@ article）
• 布局处理显示＆lt;％= render：partial =＆gt;允许？ “某事”：“别的”％＆gt;

我认为如果您不在此配置中，那么您正在创建一种后端系统。 所以它应该进入lib，然后进入gem。

这个组织只是一个例子。最重要的是组织你的代码并拆分不同的逻辑层，并且在添加新功能后不要犹豫重构/导出代码以使其成为通用的......

Answer 2

控制器的
• - 将常用方法放在application_controller.rb
中
• for Views - 将常用方法放在application_helper.rb
中
• for Models - monkeypatch ActiveRecord::Base包含常用方法或使用通用模型方法编写模块并将其包含在需要它的模型中，或者通过使用抽象类继承ActiveRecord :: Base以OOP方式执行，然后从这个类继承你的所有模型。

要在模型和控制器中使用常用方法，请执行以下操作之一：

• 编写一个普通的ruby类，将它放在/ lib或其他地方，只需确保它已加载，然后require当你需要使用它的方法时。
• 为gem提取常用功能，安装它，在需要时需要它。如果它是有价值的东西，就把它发布到rubygems。

Answer 3

在Model中，你应该存储与模型本身有关系的所有方法，比如操纵属性，范围，关联，......

在View你不存储任何逻辑！逻辑属于模型。在视图中，您只放置可帮助您显示内容的代码。

Controller是两者之间的“桥梁”。您可以在控制器中选择数据，调用存储在模型中的方法，...常见的失败是将逻辑存储在控制器中，该逻辑应存储在模型中。

当您在Model中存储方法时，您可以从模型，视图和控制器访问它！如果您的方法与特定模型无关或在多个模型中需要，则可以使用Helper。这种情况的示例可能是使用模式重写您的URL的方法。这可能需要在20个模型中为to_param准备字符串。该方法将存储在Helper中，可以包含在所需的模型中。

Answer 4

...通常，我将这些函数放入常见的超类中：对于模型，可能是（例如）动物为子类Dog，Cat等。在Animal模型中，你必须

self.abstract_class = true

所以它不期望该类的表。对于控制器，您可以使用ApplicationController，也可以使控制器由另一个公共子类派生。