ОО дизайн в рельсах: куда положить вещи

обновление: использование проблем было подтвердили как новое значение по умолчанию в Rails 4.

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

# 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 core extensions обычно имеют место в инициализаторах конфигурации, так что библиотеки загружаются только один раз на Rails boostrap.

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

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

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

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

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

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

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

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

EDIT: попытка немного расширить, надеюсь, ничего не искажая плохо...

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

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

рефакторинг моделей-это немного больше религиозная вещь. Ученики Дядя Боб предложит, например, чтобы вы следовали пяти заповедям SOLID. Джоэл И Джефф может рекомендовать более, э-э, "прагматичный" подход, хотя они действительно казались мало более примиренный впоследствии. Найти один или несколько методов внутри класса, которые работают на четко определенное подмножество его атрибутов является одним из возможных способов определения классов, может быть вынесен из вашей модели-производной модели.

модели Rails не должны быть подклассами ActiveRecord:: Base, кстати. Или, другими словами, модель не должна быть аналогом таблицы или даже связана с чем-либо, хранящимся вообще. Даже лучше, пока вы называете свой файл в app/models в соответствии с соглашениями Rails (вызов #подчеркивание имени класса, чтобы узнать, что Rails будет искать), Rails найдет его без каких-либо requires необходимо.

вот отличный пост в блоге о рефакторинге жирных моделей, которые, похоже, возникают из" тонкого контроллера " philosphy:

http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/

основное сообщение - "не извлекайте миксины из жировых моделей", вместо этого используйте классы обслуживания, автор предоставляет 7 шаблонов для этого