ОО Дизайн в Rails: куда положить вещи

Обновление. Использование Концернов было подтверждено как новый по умолчанию в Rails 4.

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

# concerns/authentication.rb
module Authentication
  ...
end    

# controllers/application_controller.rb
class ApplicationController
  include Authentication
end



# concerns/configurable.rb
module Configurable
  ...
end    

class Model 
  include Indexable
end 

# controllers/foo_controller.rb
class FooController < ApplicationController
  include Indexable
end

# controllers/bar_controller.rb
class BarController < ApplicationController
  include Indexable
end

/lib - мой предпочтительный выбор для библиотек общего назначения. У меня всегда есть пространство имен проектов в lib, где я помещаю все библиотеки, специфичные для приложения.

/lib/myapp.rb
module MyApp
  VERSION = ...
end

/lib/myapp/CacheKey.rb
/lib/myapp/somecustomlib.rb

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

/config/initializer/config.rb
/config/initializer/core_ext/string.rb
/config/initializer/core_ext/array.rb

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

Файлы-помощники обычно содержат вспомогательные методы, а иногда и классы, когда объект предназначен для использования помощниками (например, Form Builders).

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

... тенденция к огромному Подклассы ActiveRecord и огромные контроллеры вполне естественны...

"огромный" - это тревожное слово...; -)

Как ваши контроллеры становятся огромными? Это то, на что вы должны обратить внимание: в идеале контроллеры должны быть тонкими. Выбирая правильное правило из воздуха, я бы предположил, что если вы регулярно используете более, чем, скажем, 5 или 6 строк кода для каждого метода (действия) контроллера, то ваши контроллеры, вероятно, слишком толстые. Существует ли дублирование, которое может переместиться в вспомогательную функцию или фильтр? Есть ли бизнес-логика, которая может быть перенесена в модели?

Как ваши модели становятся огромными? Должны ли вы смотреть на способы сокращения числа обязанностей в каждом классе? Есть ли общее поведение, которое вы можете извлечь в миксины? Или области функциональности, которые вы можете делегировать вспомогательным классам?

РЕДАКТИРОВАТЬ: Попытка немного расширить, надеюсь, не слишком сильно искажает...

Помощники: живут в app/helpers и в основном используются, чтобы упростить просмотр. Они либо специфичны для контроллера (также доступны для всех представлений для этого контроллера), либо вообще доступны (module ApplicationHelper в application_helper.rb).

Фильтры: скажем, что у вас есть одна и та же строка кода в нескольких действиях (нередко, поиск объекта с помощью params[:id] или аналогичного). Это дублирование может быть сначала абстрагировано отдельным методом, а затем полностью исключено из действий, объявив фильтр в определении класса, например before_filter :get_object. См. Раздел 6 в ActionController Rails Guide Пусть декларативное программирование будет вашим другом.

Рефакторинг - это немного более религиозная вещь. Ученики Дядя Боб предложит, например, следовать пяти заповедям SOLID. Джоэл и Джефф могут порекомендовать более прагматичный подход, хотя они выглядели как немного более примиренные впоследствии. Поиск одного или нескольких методов в классе, которые работают с четко определенным подмножеством его атрибутов, - это один из способов попробовать идентифицировать классы, которые могут быть реорганизованы из вашей модели, основанной на 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/

Основное сообщение: "Dont Extract Mixins from Fat Models", вместо этого используйте классы обслуживания, автор предоставляет 7 шаблонов для этого