OO Diseño en Rieles: Dónde poner cosas

Update : El uso de Preocupaciones se ha confirmado como el nuevo valor predeterminado en Rails 4.

Realmente depende de la naturaleza del módulo en sí. Suelo colocar extensiones de controlador / modelo en una carpeta / concerns dentro de la aplicación.

# 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 es mi opción preferida para bibliotecas de propósito general. Siempre tengo un espacio de nombres de proyecto en lib donde pongo todas las bibliotecas específicas de la aplicación.

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

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

Las extensiones de núcleo de Ruby/Rails generalmente tienen lugar en configuración inicializadores para que las bibliotecas solo se carguen una vez en Rails boostrap.

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

Para fragmentos de código reutilizables, a menudo creo (micro)plugins para que pueda reutilizarlos en otros proyectos.

Los archivos Helper generalmente contienen métodos helper y a veces clases cuando el objeto está destinado a ser utilizado por helpers (por ejemplo, Constructores de formularios).

Esta es una visión general. Proporcione más detalles sobre ejemplos específicos si desea obtener sugerencias más personalizadas. :)

... la tendencia a hacer enormes ActiveRecord subclases y enorme controladores es bastante natural ...

"enorme" es una palabra preocupante... ;-)

¿Cómo se están haciendo enormes sus controladores? Eso es algo que deberías mirar: idealmente, los controladores deberían ser delgados. Escogiendo una regla de oro de la nada, sugeriría que si regularmente tiene más de, digamos, 5 o 6 líneas de código por método (acción) del controlador, entonces sus controladores probablemente sean demasiado gordos. Existir duplicación que podría pasar a una función auxiliar o un filtro? ¿Hay una lógica de negocios que pueda ser empujada hacia abajo en los modelos?

¿Cómo tus modelos llegan a ser enormes? ¿Debería buscar maneras de reducir el número de responsabilidades en cada clase? ¿Hay algún comportamiento común que pueda extraer en mixins? ¿O áreas de funcionalidad que puede delegar a clases auxiliares?

EDITAR: Tratando de expandir un poco, con suerte no distorsionar nada demasiado mal...

Ayudantes: en vivo en app/helpers y se utilizan principalmente para simplificar las vistas. Son específicos del controlador (también disponibles para todas las vistas de ese controlador) o generalmente disponibles (module ApplicationHelper en application_helper.po).

Filtros: Digamos que tienes la misma línea de código en varias acciones (muy a menudo, recuperación de un objeto usando params[:id] o similar). Esa duplicación se puede abstraer primero en un método separado y luego fuera de las acciones completamente declarando un filtro en la definición de la clase, como before_filter :get_object. Ver Sección 6 en la Guía de carriles de ActionController Deje que la programación declarativa sea su amiga.

Refactorizar modelos es un poco más de una cosa religiosa. Los discípulos de Tío Bob sugerirán, por ejemplo, que sigas los Cinco Mandamientos de SÓLIDO . Joel y Jeff pueden recomendar un enfoque más, er, "pragmático", aunque parecían ser un poco más reconciliados posteriormente. Encontrar uno o más métodos dentro de una clase que operar en un subconjunto claramente definido de sus atributos es una forma de intentar identificar clases que podrían ser refactorizadas de su modelo derivado de ActiveRecord.

Los modelos Rails no tienen que ser subclases de ActiveRecord::Base, por cierto. O para decirlo de otra manera, un modelo no tiene que ser un análogo de una tabla, o incluso relacionado con nada almacenado en absoluto. Aún mejor, siempre y cuando nombre su archivo en app/models de acuerdo con las convenciones de Rails (llame # underscore en el nombre de la clase para averiguar lo que Rails buscará), Rails lo encontrará sin necesidad de require.

Aquí hay una excelente entrada de blog sobre la refactorización de los modelos de grasa que parecen surgir de la filosofía del "controlador delgado":

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

El mensaje básico es "No extraiga Mixins de Modelos Fat", use clases de servicio en su lugar, el autor proporciona 7 patrones para hacerlo