Где я должен поместить функции, к которым обращаются модели?- Рельсы 3.1

Question

Мне сказали, что помощники предназначены только для функций, которые нужны представлениям.

Куда мне добавить функции, которые обычно используются моделями? А как насчет контроллеров?

Что такое соглашение о размещении часто используемых функций, которые будут использоваться в:

1) модели

2) просмотров

3) контроллеры

Проблема: Создание модуля в lib для хранения функций и включение модуля в класс создаст загрузку методов экземпляра для класса.

Проблема: Как насчет функций, которые являются общими и необходимы во всех трех?

Answer 1

Проблема: Создание модуля в lib для хранения функций и включение модуля в класс создаст загрузку методов экземпляра для класса.

Сначала организуйте, затем оптимизируйте

Проблема: как насчет функций, которые распространены и необходимы во всех трех? У вас действительно есть методы, которые нужны во всех трех и еще не существуют? Если да, может быть, вы можете дать пример

Я думаю, что вопрос должен быть в том, где поставить логику в целом. Сначала вы должны подумать о том, что делает ваш метод, прежде чем думать о том, куда его поместить. Но что бы вы ни создавали, когда оно становится большим и / или ценным, вы должны подумать об экспорте его как о драгоценном камне / плагине.

Логика внутренней навигации (что отображать и куда идти после действия): контроллеры

• Приложение для навигации по логике; application_controller
• Подмножество логики приложения; создать пространство имен с главным контроллером, класс API_controller

Логика данных (Как манипулировать, обрабатывать данные): Модели

• Данные; Метод класса модели (поиск, сортировка, подсчет, макропроцесс ...)
• Datum; Метод экземпляра модели (модификация, микропроцесс ...)

Логика представления данных (как отображать данные): вспомогательные, частичные и декораторы

• Помощник не предназначен для этого, по моему мнению.
• Частичное разметка дескрипторов конкретных данных.
• приложение-декоратор; справка по представлению общих данных
• scope_decoration; Вы можете использовать наследство

Логика языка компоновки (справка по языку компоновки): Помощник

• Специфично для вашего приложения; application_helper
• Специфично для модели ...; model_helper, но вы должны рассмотреть декоратор
• Generic; экспортировать его в гем (супер помощник по формам, система шаблонов ...)

Логика макета (я должен отобразить это меню?):?

• Помощник / декоратор / модель может ответить на вопрос: @ user.can_edit? (@ Article)
• Макет обрабатывает отображение <% = рендер: частичный => разрешено? "что-то": "что-то еще"%>

Я думаю, что если вы не в этой конфигурации, вы создаете некую бэкэнд-систему. Так что это должно войти в lib, потом в гем.

Эта организация просто пример. Самое главное - организовать свой код и разделить различные логические слои, и не стесняйтесь реорганизовать / экспортировать код, чтобы сделать его универсальным после добавления новых функций ...

Answer 2

• для контроллеров - поместить общие методы в application_controller.rb
• для представлений - поместить общие методы в application_helper.rb
• для моделей - monkeypatch ActiveRecord::Base для включения общих методов ИЛИнапишите модуль с общими методами моделей и включите его в модели, которые нуждаются в этом, или сделайте это ООП способом, создав подкласс ActiveRecord :: Base с вашим абстрактным классом, а затем унаследовав все ваши модели из этого класса.

Чтобы использовать общие методы в Model и Controller, выполните одно из следующих действий:

• Напишите простой класс ruby, поместите его в / lib или где-либо еще, просто сделайтеубедитесь, что он загружен, тогда require, когда вам нужно использовать его методы.
• Извлеките общий функционал в гем, установите его, потребуйте его, когда вам это нужно.Опубликуйте его на rubygems, если это что-то ценное.

Answer 3

В Model вы должны хранить все методы, которые имеют отношение к самой модели, например, манипулирование атрибутами, областями действия, связыванием, ...

В View вы не сохраняете никакой логики!Логика принадлежит модели.В представлении вы помещаете только код, который помогает вам отображать вещи.

Controller - это «мост» между ними.Вы выбираете данные в контроллере, вызываете методы, которые хранятся в модели, ... Общая ошибка заключается в сохранении логики в контроллере, которая должна храниться в модели.

Когда вы сохраняете метод вваш Model вы можете получить к нему доступ из модели, вида и контроллера!Если у вас есть метод, который не имеет отношения к конкретной модели или необходим в нескольких моделях, вы можете использовать Helper.Примером для такого случая может быть метод, который переписывает ваш URL, используя шаблон.Это может потребоваться в 20 моделях для подготовки строки для to_param.Этот метод будет храниться в Helper, который может быть включен в Модели, в которых он нуждается.

Answer 4

... Обычно я помещаю такие функции в общие суперклассы: для моделей, которые могут быть (например) Animal для подклассов Dog, Cat и т. Д. В модели Animal вам потребуется

self.abstract_class = true

так что он не ожидает таблицы для этого класса. Для контроллеров вы можете использовать ApplicationController или сделать ваши контроллеры производными от другого общего подкласса.