Modelo, vista, controlador y ayuda de Rails:¿Qué va a dónde?

Question

En Ruby on Rails Development (o MVC en general), ¿qué regla rápida debo seguir en cuanto a dónde colocar la lógica?

Por favor responda afirmativamente - Con Pon esto aquí, en vez de No pongas eso ahí.

Answer 1

mvc

Controlador:Coloque aquí el código que tenga que ver con determinar lo que quiere un usuario y decidir qué darle, determinar si ha iniciado sesión, si debería ver ciertos datos, etc.Al final, el controlador analiza las solicitudes y determina qué datos (modelos) mostrar y qué vistas representar.Si tiene dudas sobre si el código debería incluirse en el controlador, probablemente no debería ser así.Mantenga sus controladores flaco.

Vista:La vista solo debe contener el código mínimo para mostrar sus datos (Modelo), no debe procesar ni calcular mucho, debe mostrar datos calculados (o resumidos) por el Modelo o generados desde el Controlador.Si su Vista realmente necesita realizar un procesamiento que el Modelo o el Controlador no puede realizar, coloque el código en un Ayudante.Una gran cantidad de código Ruby en una Vista hace que el marcado de las páginas sea difícil de leer.

Modelo:Tu modelo debe estar donde todo su código que se relaciona con sus datos (las entidades que componen su sitio, p. ej.Usuarios, publicaciones, cuentas, amigos, etc.) vidas.Si el código necesita guardar, actualizar o resumir datos relacionados con sus entidades, colóquelo aquí.Será reutilizable en sus Vistas y Controladores.

Answer 2

Para agregar a la respuesta de pauliephonic:

Ayudante:funciones para facilitar la creación de la vista.Por ejemplo, si siempre está iterando sobre una lista de widgets para mostrar su precio, colóquelo en un asistente (junto con un parcial para la visualización real).O si tiene un fragmento de RJS que no desea que obstruya la vista, colóquelo en un asistente.

Answer 3

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

El diseño impulsado por dominio tiene un concepto de Servicios, que es un lugar donde se coloca la lógica que necesita orquestar una cantidad de diversos tipos de objetos, lo que generalmente significa lógica que no pertenece naturalmente a una clase de 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 sin pasar por las capas de Servicio, pero tendría que mover muchas más palancas para que funcione.

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

Answer 4

Aquí ya tienes explicaciones perfectas, una frase muy sencilla como conclusión y fácil de recordar:

Necesitamos modelos INTELIGENTES, controladores DELGADOS y vistas DUMB.

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

Answer 5

La forma Rails es tener Controladores flacos y modelos gordos..

Answer 6

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

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

Las vistas consisten en mostrar sus datos.Mostrar y obtener información únicamente.

Los controladores sirven para controlar qué datos van de su modelo a su vista (y qué vista) y de su vista a su modelo.Los controladores también pueden existir sin modelos.

Me gusta pensar en el controlador como un guardia de seguridad/recepcionista que dirige al cliente (solicitud) al mostrador apropiado donde le hace una pregunta al cajero (ver).El cajero (vista) luego va y obtiene la respuesta de un gerente (modelo), a quien nunca ve.Luego, usted realiza la solicitud y regresa con el guardia de seguridad/recepcionista (controlador) y espera hasta que le indiquen ir a otro cajero (vista) que le dice la respuesta que el gerente (modelo) les dio en respuesta a la pregunta del otro cajero (vista). .

Del mismo modo, si desea decirle algo al cajero (ver), sucede prácticamente 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 hiciera una caminata ya que usted no estaba autorizado a decirle esa información al gerente.

Entonces, para ampliar la metáfora, en mi mundo estereotipado y poco realista, los cajeros (puntos de vista) son bonitos pero tontos y a menudo creen todo lo que les dices, los guardias de seguridad/recepcionistas son mínimamente educados pero no tienen mucho conocimiento, pero saben dónde deben y No debería ir y los gerentes son realmente feos y malos, pero lo saben todo y pueden decir qué es verdad y qué no.

Answer 7

Una cosa que ayuda a separar correctamente es evitar el antipatrón "pasar variables locales del controlador a la vista".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 %>
...

Intente moverlo a un captador que esté disponible como método auxiliar:

# 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.

Answer 8

Bueno, depende en cierto modo de con qué tenga que lidiar la lógica...

A menudo, tiene sentido incluir más cosas en tus modelos, dejando los controladores pequeños.Esto garantiza que esta lógica se pueda utilizar fácilmente desde cualquier lugar donde necesite acceder a los datos que representa su modelo.Las vistas casi no deben contener lógica.Entonces, en general, debes esforzarte por lograr que no te repitas.

Además, un vistazo rápido a Google revela algunos ejemplos más concretos de qué va y dónde.

Modelo:requisitos de validación, relaciones de datos, creación de métodos, actualización de métodos, destrucción de métodos, búsqueda de métodos (tenga en cuenta que no solo debe tener las versiones genéricas de estos métodos, sino también si hay algo que esté haciendo con frecuencia, como encontrar personas pelirrojas por apellido, entonces deberías extraer esa lógica para que todo lo que tengas que hacer sea llamar a find_redH_by_name("smith") o algo así)

Vista:Todo esto debería centrarse en el formateo de datos, no en el procesamiento de datos.

Controlador:Hasta aquí llega 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 su forma final, a la vista".

Espero que ayude.

Answer 9

En términos simples, generalmente,Modelos tendrá todos los códigos relacionados con las tablas, sus relaciones simples o complejas (piense en ellas como consultas SQL que involucran varias tablas), manipulación de los datos/variables para llegar a un resultado utilizando la lógica de negocios.

Controladores tendrá códigos/indicadores hacia los modelos relevantes para el trabajo solicitado.

Puntos de vista aceptará la entrada/interacción del usuario y mostrará la respuesta resultante.

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

Answer 10

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

j