Modelo, Vista, Controlador y Ayudante de Rails: ¿qué va a dónde?

Para añadir a la respuesta de pauliephonic:

Helper : funciones para facilitar la creación de la vista. Por ejemplo, si siempre está iterando sobre una lista de widgets para mostrar su precio, póngalo en un ayudante (junto con un parcial para la visualización real). O si tienes un pedazo de RJS que no quieres que estorbe la vista, ponlo en un ayudante.

El patrón MVC realmente solo se refiere a la interfaz de usuario y nada más. No debe poner ninguna lógica de negocio compleja en el controlador, ya que controla la vista, pero no la lógica. El Controlador debe preocuparse por seleccionar la vista adecuada y delegar cosas más complejas al modelo de dominio (Modelo) o a la capa de negocio.

Domain Driven Design tiene un concepto de Servicios que es un lugar donde se pega la lógica que necesita orquestar una serie de diversos tipos de objetos que generalmente significa lógica que no pertenece naturalmente a una clase Modelo.

Generalmente pienso en la capa de servicio como la API de mis aplicaciones. Mis capas de servicios generalmente se corresponden bastante con los requisitos de la aplicación que estoy creando, por lo que la capa de servicio actúa como una simplificación de las interacciones más complejas que se encuentran en los niveles inferiores de mi aplicación, es decir, podría lograr el mismo objetivo evitando las capas de Servicio, pero tendría que tirar de muchas más palancas para hacerlo trabajo.

Tenga en cuenta que no estoy hablando de Rails aquí estoy hablando de un estilo arquitectónico general que aborda su problema particular.

Explicaciones perfectas aquí ya, una frase muy simple como conclusión y fácil de recordar:

Necesitamos Modelos INTELIGENTES, Controladores DELGADOS y Vistas TONTAS.

Http://c2.com/cgi/wiki?ModelViewController

La forma de Rails es tener controladores skinny y modelos fat.

Ponga cosas relacionadas con la autorización/control de acceso en el controlador.

Los modelos tienen que ver con tus datos. Validación, Relaciones, CRUD, Lógica de negocios

Las vistas se tratan de mostrar sus datos. Mostrar y obtener solo la entrada.

Los controladores se encargan de controlar qué datos van de tu modelo a tu vista (y qué vista) y de tu vista a tu modelo. Los controladores también pueden existir sin modelos.

Me gusta pensar en el controlador como una seguridad guardia / recepcionista que le dirige al cliente (solicitud)al mostrador apropiado donde le hace una pregunta a un cajero (ver). El cajero (vista) entonces va y obtiene la respuesta de un gerente (modelo), a quien nunca ves. Usted la solicitud a continuación, volver al guardia de seguridad / recepcionista (controlador) y esperar hasta que se le indica que vaya otro cajero (ver) que le dice la respuesta que el gerente (modelo) les dijo en respuesta a la pregunta del otro cajero (ver).

Lo mismo si quieres dile al cajero (ver) algo, entonces en gran medida sucede lo mismo, excepto que el segundo cajero le dirá si el gerente aceptó su información. También es posible que el guardia de seguridad/recepcionista (controlador) le haya dicho que tome una caminata ya que no estaba autorizado a decirle al gerente esa información.

Así que para extender la metáfora, en mi mundo estereotipado y poco realista, los cajeros (puntos de vista) son bonitos pero con la cabeza vacía y a menudo creen todo lo que les dices, guardia de seguridad / recepcionistas son mínimamente educados, pero no son muy bien informados, pero saben a dónde debe y no debe ir la gente y los gerentes son realmente feos y malos, pero saben todo y pueden decir lo que es verdad y lo que no lo es.

Una cosa que ayuda a separar correctamente es evitar el anti-patrón "pasar variables locales del controlador para ver". En lugar de esto:

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  def show
    @foo = Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= @foo.bar %>
...

Intenta moverlo a un getter que esté disponible como método helper:

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  helper_method :foo

  def show
  end

  protected

  def foo
    @foo ||= Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= foo.bar %>
...

Esto hace que sea más fácil modificar lo que se pone en "@foo" y cómo se usa. Aumenta la separación entre el controlador y la vista sin hacerlos más complicados.

Bueno, depende de lo que la lógica tiene que lidiar...

A menudo, tiene sentido introducir más cosas en sus modelos, dejando controladores pequeños. Esto garantiza que esta lógica se pueda usar fácilmente desde cualquier lugar que necesite para acceder a los datos que representa su modelo. Las vistas no deberían contener casi ninguna lógica. Así que realmente, en general, debes esforzarte para que no te Repitas.

Además, un poco rápido de Google revela algunos ejemplos más concretos de lo que va a dónde.

Modelo: requisitos de validación, relaciones de datos, crear métodos, actualizar métodos, destruir métodos, encontrar métodos (tenga en cuenta que no solo debe tener las versiones genéricas de estos métodos, sino que si hay algo que está haciendo mucho, como encontrar personas con el pelo rojo por apellido, entonces debe extraer esa lógica para que todo lo que tiene que hacer es llamar al find_redH_by_name ("smith") o algo así)

Vista: Esto debe ser todo sobre el formato de los datos, no el tratamiento de datos.

Controlador: Aquí es donde va el procesamiento de datos. Desde Internet: "El propósito del controlador es responder a la acción solicitada por el usuario, tomar cualquier parámetro que el usuario haya establecido, procesar los datos, interactuar con el modelo y luego pasar los datos solicitados, en forma final, a la vista."

Espero que eso ayude.

En términos simples, generalmente, Los modelos tendrán todos los códigos relacionados con la(s) tabla (s), sus relaciones simples o complejas (piense que son consultas sql que involucran múltiples tablas), manipulación de los datos/variables para llegar a un resultado utilizando la lógica de negocio.

Los controladores tendrán código/punteros hacia los modelos relevantes para el trabajo solicitado.

Views aceptará la entrada/interacción del usuario y mostrará la respuesta resultante.

Cualquiera una desviación importante de estos pondrá tensión no deseada en esa parte y el rendimiento general de la aplicación puede verse afectado.

Probando, Probando ... Ponga tanta lógica como sea posible en el modelo y entonces usted será capaz de probarlo correctamente. Las pruebas unitarias prueban los datos y la forma en que se forman al probar el modelo, y las pruebas funcionales prueban la forma en que se enrutan o controlan al probar los controladores, por lo que no puede probar la integridad de los datos a menos que estén en el modelo.

J