Поскольку Rails предоставляет структуру с точки зрения MVC, естественно, в конечном итоге будет использоваться только та модель, представление и контейнеры контроллера, которые вам предоставлены. Типичная идиома для начинающих (и даже некоторых программистов среднего уровня) заключается в том, чтобы втиснуть всю логику в приложении в модель (класс базы данных), контроллер или представление.
В какой-то момент кто-то указывает на парадигму «толстая модель, тощий контроллер», и промежуточные разработчики поспешно отсекают все от своих контроллеров и бросают это в модель, которая начинает становиться новой корзиной для логики приложения.
Тощие контроллеры, на самом деле, хорошая идея, но следствие - поместить все в модель - не самый лучший план.
В Ruby у вас есть несколько хороших вариантов для того, чтобы сделать вещи более модульными. Довольно популярный ответ - просто использовать модули (обычно спрятанные в них lib
), которые содержат группы методов, а затем включать модули в соответствующие классы. Это помогает в тех случаях, когда у вас есть категории функциональности, которые вы хотите использовать повторно в нескольких классах, но когда функциональность все еще условно привязана к классам.
Помните, что когда вы включаете модуль в класс, методы становятся методами экземпляра класса, так что вы все равно получаете класс, содержащий массу методов, они просто хорошо организованы в несколько файлов.
Это решение может работать хорошо в некоторых случаях - в других случаях вам нужно подумать об использовании в коде классов, которые не являются моделями, представлениями или контроллерами.
Хороший способ думать об этом - это «принцип единой ответственности», который гласит, что класс должен нести ответственность за одно (или небольшое количество) вещей. Ваши модели отвечают за сохранение данных из вашего приложения в базу данных. Ваши контролеры несут ответственность за получение запроса и возврат жизнеспособного ответа.
Если у вас есть концепции, которые не вписываются в эти рамки (постоянство, управление запросами / ответами), вы, вероятно, захотите подумать о том, как бы вы смоделировали данную идею. Вы можете хранить немодельные классы в приложении / классах или в любом другом месте и добавить этот каталог в путь загрузки, выполнив:
config.load_paths << File.join(Rails.root, "app", "classes")
Если вы используете пассажир или JRuby, вы, вероятно, также захотите добавить свой путь к путям активной загрузки:
config.eager_load_paths << File.join(Rails.root, "app", "classes")
Суть в том, что как только вы дойдете до точки в Rails, где вы обнаружите, что задаете этот вопрос, пришло время усилить ваши рубиновые отбивные и начать моделировать классы, которые не являются просто классами MVC, которые Rails предоставляет вам по умолчанию.
Обновление: этот ответ относится к Rails 2.x и выше.
Обновление : использование проблем было подтверждено как новое значение по умолчанию в Rails 4 .
Это действительно зависит от природы самого модуля. Я обычно помещаю расширения контроллера / модели в папку / Concerts внутри приложения.
/ lib - мой предпочтительный выбор для библиотек общего назначения. У меня всегда есть пространство имен проекта в lib, куда я помещаю все библиотеки приложений.
Расширения ядра Ruby / Rails обычно имеют место в инициализаторах конфигурации, так что библиотеки загружаются только один раз в boostrap Rails.
Для многократно используемых фрагментов кода я часто создаю (микро) плагины, чтобы их можно было использовать в других проектах.
Вспомогательные файлы обычно содержат вспомогательные методы и иногда классы, когда объект предназначен для использования помощниками (например, Form Builders).
Это действительно общий обзор. Пожалуйста, предоставьте более подробную информацию о конкретных примерах, если вы хотите получить больше индивидуальных предложений. :)
источник
"огромный" это тревожное слово ... ;-)
Как ваши контроллеры становятся огромными? Это то, на что вам следует обратить внимание: в идеале контроллеры должны быть тонкими. Выбирая эмпирическое правило из чистого воздуха, я бы предложил, что если у вас регулярно есть, скажем, 5 или 6 строк кода на метод (действие) контроллера, то ваши контроллеры, вероятно, слишком толстые. Есть ли дублирование, которое может перейти в вспомогательную функцию или фильтр? Есть ли бизнес-логика, которая могла бы быть внедрена в модели?
Как ваши модели становятся огромными? Стоит ли искать способы уменьшить количество обязанностей в каждом классе? Есть ли какие-либо общие поведения, которые вы можете извлечь в mixins? Или области функциональности, которые вы можете делегировать вспомогательным классам?
РЕДАКТИРОВАТЬ: Попытка немного расширить, надеюсь, не слишком сильно искажая ...
Помощники: живут
app/helpers
и в основном используются для упрощения просмотра. Они либо специфичны для контроллера (также доступны для всех представлений для этого контроллера), либо обычно доступны (module ApplicationHelper
в application_helper.rb).Фильтры: скажем, у вас одна и та же строка кода в нескольких действиях (довольно часто при извлечении объекта с использованием
params[:id]
или аналогичных). Это дублирование может быть абстрагировано сначала для отдельного метода, а затем полностью исключено из действия путем объявления фильтра в определении класса, такого какbefore_filter :get_object
. См. Раздел 6 Руководства по рельсам ActionController. Пусть декларативное программирование станет вашим другом.Рефакторинг моделей - это скорее религиозная вещь. Ученики дяди Боба предложат, например, что вы будете следовать пяти заповедям твердого тела . Джоэл и Джефф могут порекомендовать более «прагматичный» подход, хотя они выглядят немного более согласованными впоследствии . Поиск одного или нескольких методов в классе, которые работают с четко определенным подмножеством его атрибутов, является одним из способов определения классов, которые могут быть реорганизованы из вашей модели, производной от ActiveRecord.
Кстати, модели Rails не обязательно должны быть подклассами ActiveRecord :: Base. Или, другими словами, модель не должна быть аналогом таблицы или даже иметь отношение к чему-либо, что хранится вообще. Более того, если вы называете свой файл в
app/models
соответствии с соглашениями Rails (вызовите #underscore в имени класса, чтобы узнать, что будет искать Rails), Rails найдет его безrequire
необходимости.источник
Вот отличное сообщение в блоге о рефакторинге толстых моделей, которые, похоже, возникли из философии «тонкого контроллера»:
http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
Основное сообщение: «Не извлекать миксины из жировых моделей», вместо этого используйте классы обслуживания, для этого автор предлагает 7 шаблонов.
источник