Flujo de aplicación de Ruby on Rails

Cuando escribe sus propios programas de principio a fin, es fácil ver control de flujo. El programa comienza aquí, hay un bucle allí, las llamadas a métodos están aquí, todo es visible. Pero en una aplicación Rails, las cosas no son tan simples. Con un marco de cualquier tipo, renuncia al control de cosas como "flujo" en favor de una forma más rápida o más simple de realizar tareas complejas. En el caso de Ruby on Rails, el control de flujo se maneja detrás de escena y todo lo que queda es (más o menos) una colección de modelos, vistas y controladores.

El núcleo de cualquier aplicación web es HTTP. HTTP es el protocolo de red que utiliza su navegador web para comunicarse con un servidor web. Aquí es de donde provienen términos como "solicitud", "OBTENER" y "POSTAR", son el vocabulario básico de este protocolo. Sin embargo, dado que Rails es una abstracción de esto, no pasaremos mucho tiempo hablando de ello.

Cuando abra una página web, haga clic en un enlace o envíe un formulario en un navegador web, el navegador se conectará a un servidor web a través de TCP / IP. Luego, el navegador envía una "solicitud" al servidor, considérelo como un formulario de correo que el navegador completa solicitando información en una página determinada. El servidor finalmente envía al navegador web una "respuesta". Sin embargo, Ruby on Rails no es el servidor web, el servidor web puede ser cualquier cosa de Webrick (lo que generalmente ocurre cuando inicia un servidor Rails desde el

Una de las primeras cosas que hace una aplicación Rails con una solicitud es enviarla a través del enrutador. Cada solicitud tiene una URL, esto es lo que aparece en la barra de direcciones de un navegador web. El enrutador es lo que determina qué se debe hacer con esa URL, si la URL tiene sentido y si la URL contiene algún parámetro. El enrutador está configurado en config / routes.rb.

Primero, sepa que el objetivo final del enrutador es hacer coincidir una URL con un controlador y una acción (más sobre esto más adelante). Y dado que la mayoría de las aplicaciones de Rails son RESTful, y las cosas en las aplicaciones RESTful se representan utilizando recursos, verá líneas como recursos: publicaciones en aplicaciones típicas de Rails. Esto coincide con URL como /posts/7/edit con el controlador Posts, el editar acción en la publicación con el ID de 7. El enrutador simplemente decide a dónde van las solicitudes. Entonces nuestro bloque [Rails] puede expandirse un poco.

Ahora que el enrutador ha decidido a qué controlador enviar la solicitud y a qué acción en ese controlador, lo envía. Un controlador es un grupo de acciones relacionadas, todas agrupadas en una clase. Por ejemplo, en un blog, todo el código para ver, crear, actualizar y eliminar publicaciones de blog se agrupa en un controlador llamado "Publicar". Las acciones son normales métodos de esta clase Los controladores están ubicados en aplicación / controladores.

Digamos que el navegador web envió una solicitud de /posts/42. El enrutador decide que esto se refiere a Enviar controlador, el espectáculo método y el ID de la publicación para mostrar es 42, entonces llama al espectáculo Método con este parámetro. los espectáculo El método no es responsable de usar el modelo para recuperar los datos y usar la vista para crear la salida. Entonces nuestro bloque expandido [Rails] es ahora:

El modelo es el más simple de entender y el más difícil de implementar. El modelo es responsable de interactuar con la base de datos. La forma más sencilla de explicarlo es que el modelo es un conjunto simple de llamadas a métodos que devuelven objetos Ruby simples que manejan todas las interacciones (lecturas y escrituras) de la base de datos. Entonces, siguiendo el ejemplo del blog, la API que usará el controlador para recuperar datos usando el modelo se verá algo así como Post.find (params [: id]). los params es lo que el enrutador analizó desde la URL, Post es el modelo. Esto hace consultas SQL, o hace lo que sea necesario para recuperar la publicación del blog. Los modelos se encuentran en aplicación / modelos.

Es importante tener en cuenta que no todas las acciones necesitan usar un modelo. La interacción con el modelo solo es necesaria cuando los datos deben cargarse desde la base de datos o guardarse en la base de datos. Como tal, pondremos un signo de interrogación después en nuestro pequeño diagrama de flujo.

Finalmente, es hora de comenzar a generar algo de HTML. HTML no es manejado por el controlador en sí, ni es manejado por el modelo. El punto de usar un marco MVC es compartimentar todo. Las operaciones de la base de datos permanecen en el modo, la generación de HTML permanece en la vista y el controlador (llamado por el enrutador) los llama a ambos.

HTML normalmente se genera utilizando Ruby incrustado. Si está familiarizado con PHP, es decir, un archivo HTML con código PHP incrustado en él, entonces Ruby incrustado estará muy familiarizado. Estas vistas se encuentran en aplicación / vistas, y un controlador llamará a uno de ellos para generar la salida y enviarla de vuelta al servidor web. Los datos recuperados por el controlador que usa el modelo generalmente se almacenarán en un Instancia variable que, gracias a la magia de Ruby, estará disponible como variables de instancia desde la vista. Además, Ruby incrustado no necesita generar HTML, puede generar cualquier tipo de texto. Verá esto cuando genere XML para RSS, JSON, etc.

Esta salida se envía de vuelta al servidor web, que la envía de vuelta al navegador web, que completa el proceso.