Как организовать слишком толстые модели Rails?

Question

Хорошей практикой является переключение логики с контроллера в модель. Но в любой сложной системе это неизменно приводит к очень большому файлу, даже если большинство методов являются однострочными согласно Rails Way.

Я прибег к разделению моделей на другие модули и включению их в исходную модель, например, model_flags, model_validation и т. Д. У кого-нибудь есть способ получше?

Изменить: я выбрал новый ответ, который предложил использовать ActiveConcern. Кроме того, всем, кто интересуется организацией кода, эта статья, Создание моделей ActiveRecord Thin , должна очень помочь.

Answer 1

Я понимаю, что это довольно старый вопрос, и он помечен как отвеченный, но в нем все еще есть хороший гугл-сок, поэтому я решил, что его стоит добавить к ...

В Rails 3 появился ActiveSupport :: Concern, который можно использовать для модульного поведения, общего для всех моделей. Или, в этом отношении, чтобы похудеть модели, которые стали слишком толстыми.

Сам DHH дает хороший, краткий пример суть здесь:

https://gist.github.com/1014971

Answer 2

Я бы не стал этого делать по нескольким причинам.

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

Во-вторых, вы почти ничего не получаете от этого и что-то теряете. Размер файла не имеет значения в наши дни, когда почти все редакторы и IDE облегчают навигацию больших файлов. Перемещение элементов в модуль фактически устраняет некоторые из этих современных недостатков и требует от вас, ваших коллег или будущих сопровождающих лиц перебирать еще несколько файлов при работе с одной моделью.

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

Answer 3

Что ж, я бы не сказал, что кто-то из вас не прав, когда помещает все в одну модель, но я думаю, что вполне уместно разделять различные проблемы. Это компромисс по крайней мере.

И я публикую ответ на свой вопрос, так как я нашел Rails Way для этого: http://github.com/jakehow/concerned_with

Более подробную информацию можно найти здесь: http://m.onkey.org/2008/9/15/active-record-tips-and-tricks

Answer 4

• Вы можете использовать сервисные объекты: http://railscasts.com/episodes/398-service-objects
• Вы также можете использовать проблемы. Папка для него создается по умолчанию в рельсах 4: http://railscasts.com/episodes/400-what-s-new-in-rails-4

Answer 5

Не зная вашей объектной модели, советовать немного сложнее, но я бы сказал, что если вы абсолютно уверены, что все проверки / ассоциации / обратные вызовы нуждаются в , чтобы быть в этом место, есть все еще способы вычленить общее поведение. Поэтому, хотя я бы не просто переместил большой кусок кода из одного файла в другой, где он просто заново открывает класс, я бы сказал, что использование модулей / плагинов для описания распространенных типов поведения - хорошая идея.

Например, если вы создаете фид активности в стиле Facebook и все должно генерировать «события», то, возможно, вы захотите перенести это «Eventable» поведение в модуль, который при включении определяет ассоциации / валидации / и т.д.. Я бы сказал, что такой подход фактически улучшил бы ясность вашего кода, поскольку ручное указание этих ассоциаций повсюду не так выразительно, как объявление чего-либо как Eventable, и не так безопасно (вы бы дублировали логику во многих местах и когда логика меняется, остальное ты знаешь ...)

В целом, я бы сказал, взгляните на вашу объектную модель. Если в вашем наборе тестов вы заметили, что все ваши тесты требуют большой настройки, это может быть хорошим индикатором того, что вы что-то упустили в своей объектной модели. Опять же, хотя бы пример кода был бы хорош.

Answer 6

Модули звучит разумно. Я не стал бы извлекать вызовы методов (проверки, обратные вызовы, плагины и т. Д.) В модули, хотя я бы ограничил извлечение моими собственными методами.

И, как всегда, было бы полезно, если бы вы опубликовали пример кода. Мне трудно представить общую стратегию очистки моделей, это зависит от характера кода.