AWD 03: La arquitectura de las aplicaciones Rails - LPC-Ltda/Ruby-on-Rails GitHub Wiki

##3.1 Modelos vistas y controladores

Hacia 1979, Trygve Reenskaug llega con una nueva arquitectura para el desarrollo de aplicaciones interactivas. En su diseño, las aplicaciones se rompen en tres tipos de componentes: modelos, vistas y controladores.

El modelo es el responsable de mantener el estado de la aplicación. Algunas veces este estado es transiente, durando sólo un par de interacciones con el usuario. Algunas veces el estado es permanente y será almacenado fuera de la aplicación, frecuentemente en una base de datos.

Un modelo es más que sólo data; este aplica todas las reglas de negocios que aplican a la data. Por ejemplo, si un descuento no puede ser aplicado a ordenes de menos de $20, el modelo debe garantizar esta restricción. Esto hace sentido; poniendo la implementación de estas reglas de negocios en el modelo, nos aseguramos que nada más en la aplicación puede hacer que nuestra data sea no-valida. El modelo actúa tanto como cuidador de acceso como de almacén de datos.

La vista es responsable de generar la interface de usuario, normalmente basado en la data del modelo.

Los controladores orquestan la aplicación. Reciben eventos desde el mundo exterior (normalmente el input del usaurio). Interactúan con el modelo, y despliegan una vista apropiada para el usuario.

Figura 5 La arquitectura Modelo-Vista-Controlador

En una aplicación Rails, un requerimiento entrante es primero enviado a un router, el cual resuelve donde debe ser enviado el requerimiento en la aplicación y como debe ser parseado el mismo request. Finalmente esta fase identifica un método particular (llamado action en la jerga Rails) en alguna parte del código del controlador. La action puede mirar la data en el requerimiento, podría interactuar con el modelo, y puede causar que otras actions sean invocadas. Eventualmente, la acción prepara información para la vista, la cual renderea algo para el usuario.

El controlador le cuenta que hacer y el modelo sabe como hacerlo.

##3.2 Soporte de modelos de Rails

En general desearemos que nuestras aplicaciones pongan su información en una base de datos relacional. Las que almacenaran la información en tablas.

Aunque no se desprende fácilmente del SQL que usted usa para accesarlos, las bases de datos relacionales están realmente diseñadas en torno a la teoría de conjuntos matemática. Aunque esto es bueno desde un punto de vista conceptual, hace difícil combinar las bases de datos relacionales con lenguajes de programación orientados a objetos (OO). Los objetos se refieren a datos y operaciones y las bases de datos a conjuntos de valores. Las operaciones que son fáciles de expresar en términos relacionales son en ocasiones difíciles de codificar en sistemas OO. Lo contrario es también verdadero.

Veamos la forma que Rails elige para mapear data relacional en objetos.

Mapeo relacional de objetos (ORM)

Las librerías ORM mapean tablas de bases de datos a clases. Si una base de datos tiene una tabla llamada orders, nuestro programa tendrá una clase llamada Order. Las filas en esta tabla corresponden a objetos de la clase -una order particular es representada como un objeto de la clase Order. Dentro de este objeto, los atributos son usados para tener y setear las columnas individuales.

Adicionalmente, las clases Rails que envuelven nuestras tablas de bases de datos proveen un conjunto de métodos a nivel de clase que realizan operaciones a nivel de tabla. Por ejemplo, podemos necesitar encontrar una order con un ID particular.

order = Order.find(1)
puts "Customer #{order.customer_id}, amount=$#{order.amount}"

Algunas veces los métodos retornan colecciones de objetos

Order.where(name: 'dave').each do |order|
  puts order.amount
end

Order.where(name: 'dave').each do |order|
  order.pay_type = "Purchase order"
  order.save
end

En una librería ORM típica, usted proporciona data de configuración para especificar el mapeo entre entidades en la base de datos y las entidades en el programa. Los programadores que usan herramientas ORM frecuentemente se encuentran creando y manteniendo muchos archivos de configuración.

Active Record

Active Record es la capa ORM proporcionada por Rails. Este difiere de la mayoría de otras librerías ORM en la forma en que es configurado. Descansando en la convención y definiendo defaults sensibles, Active Record minimiza la cantidad de configuración que los desarrolladores realizan.

require 'active_record'

class Order < ActiveRecord::Base
end

order = Order.find(1)
order.pay_type = "Purchase order"
order.save

Active Record nos evita tener que lidiar con la base de datos subyacente, dejándonos libres para trabajar en la lógica de negocios. Pero Active Record hace más que eso, pues se integra sensiblemente con el resto del framework Rails. Si un formulario web envía a la aplicación data relacionada con un objeto de negocio, Active Record puede extraerla de nuestro modelo, soportar validaciones sofisticadas al modelo de datos y si el formulario de data falla las validaciones, las vistas de Rails pueden extraer y formatear errores.

##3.3 ActionPack: La vista y el controlador

La relación entre vistas y controlador es intima. El controlador entrega data a la vista y recibe eventos desde las páginas generadas por las vistas. Debido a esta interacciones es porque en Rails vistas y controladores estan ligados a componente único Action Pack.

Soporte de Vistas

En Rails, la vista es responsable de la creación de todo o parte de una respuesta para ser desplegada en el browser, para ser procesada por la aplicación, o para ser enviada a un email. En simple, una vista es un pedazo de HTML, código que despliega algo de código fijo. Más típicamente deseará incluir contenido dinámico creado por el método de acción en el controlador.

En Rails, el contenido dinámico es generado por templates, los cuales vienen en tres sabores. El esquema de template más común, llamado Ruby embuido (ERB), inserta pedazos de codigo Ruby en un dócumento vista.

Usted puede también usar ERB para construir fragmentos JavaScript en el servidor que son entonces ejecutados por el browser. Esto es bueno para la creación de interfaces dinámicas Ajax.

Rails también provee contructores XML para construir documentos XML usando codigo Ruby -la estructura del XML generado seguirá automáticamente la estructura del código.

Y el controldor!

El controlador Rails es el centro lógico de su aplicación. Este coordina la interacción entre el usuario, las vistas, y el modelo. Sin embargo Rails maneja mucha de esta interacción detrás de la escena; el código que usted escribe se concentra en la funcionalidad a nivel de la aplicación. Esto hace el código del controlador de Rails muy fácil de desarrollar y mantener.

El controlador es también hogar de un número importante de servicios auxiliares.

• Es responsable de rutear requerimientos externos a acciones internos. Maneja URL amigables al usuario muy bien.
• Maneja el caching, lo cual puede darle a las aplicaciones un aumento de su desempeño de orden de magnitud.
• Maneja módulos helper, lo cual extiende las capacidades de los templates de vistas sin abultar su código.
• Maneja sesiones, dándole a los usuarios la impresión de interacción sobre la marcha con sus aplicaciones.