Dibujando la línea entre el modelo y el controlador

Question

Estoy construyendo esta aplicación relajante usando RoR, y me resulta un poco difícil trazar una línea entre las cosas que deberían ir en el modelo y las cosas que deberían ir en el controlador .

Como ejemplo, tengo 7 métodos en mi controlador (los que lo hacen relajante, es decir, index(), show(), create(), update() ...), y a menudo encuentran que es necesario agregue métodos adicionales y hágalo al crearlos como miembros.

Lo que me gustaría lograr aquí, es la adquisición de experiencia de ustedes sobre lo que ocurre cuando (es decir, debo pegar todas las interacciones de bases de datos en el modelo, y simplemente llamar a estos métodos desde el controlador?)

Además, agregando cosas que no involucran DB a mi controlador, es decir, quiero hacer una llamada HTTP para revisar algunos datos de un sitio web.

Las llamadas HTTP pueden ser grandes y complicadas. ¿Debería todo esto ir a mi controlador, o debería ser una clase o módulo separado, y solo debe incluirse en mi controlador para que pueda ser llamado?

Si es así, ¿cuál sería el mejor enfoque para hacerlo?

Estoy un poco confundido con todo esto, por lo que sería genial tener la opinión de alguien.

Gracias de antemano

Answer 1

Es una parte de Domain Driven Design.

El dominio es el ámbito de conocimiento que define el área con la que la aplicación intenta trabajar y resolver problemas.

La capa Modelo se considera capa de dominio. Es aquí donde se guardan todas las reglas que definen el Dominio o la lógica de negocios. El modelo actúa como un filtro entre los datos reales y el resto de la aplicación de una manera que define el dominio.

Los detalles de implementación del dominio (mySQL o MSSql o servicio web o archivo Xml o página web externa o lo que sea) están ocultos por el modelo.

El controlador es solo el messenger. Su trabajo es tomar mensajes del usuario y pasarlos al Modelo. El Modelo da una respuesta y el Controlador determina la mejor manera de pasarle esto al usuario.

The View es como el artista de maquillaje, solo asegurándose de que los datos se vean bien y presentables para el usuario.

El sitio web que está raspando podría considerarse parte del dominio. Este sitio contiene conocimiento que define el mundo que su aplicación está definiendo. El proceso de screencraping está esculpiendo ese conocimiento de una manera tal que se relacione con el resto de la vista del mundo que su aplicación está definiendo. Al controlador no le importa de dónde proviene este conocimiento, simplemente pasará el mensaje a la vista. ¡The View se preocupará por los datos, lo hará bonito y se lo enviará al usuario, que es completamente ajeno a todo el proceso y solo ve una bonita página web!

Answer 2

Cuando he utilizado llamadas SOAP de rieles, que es similar a lo que estás hablando de una manera, traté a los que como fuente de datos, por lo que mi mente pertenecían en el modelo. También puede elegir, si la funcionalidad es algo genérica, escribir un complemento para hacer ese trabajo también, o encontrar un complemento que haga la mayor parte de lo que ya quiere y utilizarlo.

En caso de duda, piense en su modelo como la aplicación y su vista/controlador como interfaz. Si no es claramente una interfaz, probablemente pertenezca al Modelo.

This question may help.

Answer 3

El material raspado debe ir en un modelo no ActiveRecord, y el controlador simplemente debe llamar a los métodos de este modelo.

Hay un bonito example de un modelo AR sin mesa, y one de un modelo no AR en railscasts.

Por lo tanto, el controlador podría hacer algo como:

def index 
    @some_things = SomeThing.all 
end 

def show 
    @some_thing = SomeThing.find params[......] 
end 

Y su modelo SomeThing implementaría la lógica necesaria.

Answer 4

En términos generales, un buen enfoque (sin religión llama, PLZ) es tener controladores delgadas y gordas modelos. De esa manera también puede probar fácilmente "las cosas" que se supone que deben hacer los modelos ...

Answer 5

Me atengo a las reglas del controlador delgado y los modelos de grasa.

Dado un enfoque tranquilo, mantengo todos los controladores en este estándar y no tengo más métodos en ellos fuera del valor predeterminado. Si requiero una nueva funcionalidad y advierto que los métodos hacen cosas similares (o tendrían una denominación similar e.g group_add, group_remove) Creo un nuevo controlador y uso los modelos existentes y creo nuevos métodos en el modelo.

Esto también permite un enfoque relajante para estas acciones adicionales de una manera significativa y específicamente cada acción tiene una especificación estrechamente definida para su funcionamiento, nunca hará más de una cosa. Nada peor que usar una llamada API que hace dos cosas dependiendo de cómo se llama.

Un enfoque que uso es manejar la solicitud lo más "rápido" posible utilizando tan poco código como sea necesario y abstrayendo tareas/operaciones complejas al modelo.

Answer 6

También prefiero controladores delgados y modelos de grasa ... Una buena herramienta para ayudarlo a hacer cumplir esta regla es la gema inherited_resources de José Valim. Sugiero que lo eche un vistazo: http://github.com/josevalim/inherited_resources