Los patrones son una parte importante en el desarrollo de aplicaciones, ya que nos proporcionan soluciones probadas para problemas comunes o recurrentes.
En este caso el patrón MVC ofrece una metodología consistente en el desarrollo de aplicaciones que interactuan con el usuario para la manipulación de información.
MVC es un patrón de arquitectura y que debe su nombre a los tres elementos que lo componen, Model-View-Controller (Modelo-Vista-Controlador). El objetivo de este patrón es separar la lógica de negocios de la interface gráfica de manera que cambios en la misma no afecten a la lógica de negocios. A este concepto de aislar bloques de nuestra aplicación de otros mas que la componen se le conoce como "Separación de preocupaciones" (
Separation of concerns - SoC -)
El modelo representa a la información que tanto el usuario como la aplicación puede manipular. La vista implica todos los elementos que componen la interface gráfica, como cuadros de texto, botones, rejillas, etc.
El controlador maneja la interacción y la comunicación entre el modelo y las acciones del usuario como teclas o movimientos del mouse.
Este patrón fue descrito en 1979 por
Trygve Reenskaug y fue implementado inicialmente en el lenguaje
Smalltalk. Durante este tiempo, este patron ha sido implementado en una gran cantidad de Frameworks para aplicaciones Web y de escritorio como:
Aunque últimamente ha cobrado popularidad en el desarrollo de aplicaciones Web, su uso en aplicaciones de escritorio es extendido, por ejemplo Oracle Applications, que es el software ERP de Oracle, ha migrado algunos de sus módulos de Oracle Forms al framework Oracle Applications Framework.
Otro caso es OSX cuyo modelo de programación para aplicaciones con el framework Cocoa es basado en el patrón MVC, por lo tanto, prácticamente todas las aplicaciones que se ejecutan en OSX funcionan con este patrón.
Después de esta introducción nos vamos a enfocar en como el framework ASP.NET MVC funciona y de que manera lo podemos utilizar en conjunto con el
patrón ActiveRecord implementado por Castle ActiveRecord.
El
Microsoft ASP.NET MVC framework es relativamente nuevo, a finales del 2007 se anuncio sobre el inicio de sus desarrollo, durante este tiempo Microsoft ha hecho publico su código fuente (bajo una licencia muy limitada), ademas de publicar cinco "Code Previews" y con la promesa de tener una versión beta disponible en los próximos meses.
La forma en como este patrón funciona en ASP.NET MVC se describe a continuación
- El usuario navega hacia una URL de nuestro sitio web
- El controlador correcto recibe la acción que se debe ejecutar
- El controlador se comunica para modelo para indicar alguna acción a tomar
- El modelo regresa datos si es que la acción que se esta ejecutando así lo requiere
- El controlador pasa los datos a la vista a través del objeto ViewData, y llama a la vista
- La vista, que funciona como plantilla, genera el código HTML que se desplegara en el navegador del usuario al final de la acción.
ASP.NET MVC FrameworkLa introducción presentada aquí al ASP.NET MVC Framework es una introducción rápida, donde se omiten algunos detalles conscientemente con la finalidad de que el post no sea muy largo, ademas de que el tema aquí tratado se vio en el curso que se llevo a cabo en el ITT.
Cuando creamos un nuevo proyecto para MVC desde Visual Studio, por omisión se crea la siguiente estructura de de directorios, que si bien no es necesario usarla estrictamente, si es recomendable utilizarla:
/Controllers
/Models
/Views
En el directorio Controllers es donde debemos colocar nuestras clases que funcionan como controladores, Models es donde deben de ir nuestras clases que representan datos y finalmente Views es donde colocamos nuestras plantillas ASP.NET que se van a encargar de generar nuestra interface HTML.
El ControladorEn ASP.NET MVC existe una convención por omisión acerca de como vamos a nombrar las clases que corresponden a nuestros controladores, esta convención nos indica que por ejemplo para nuestro controlador de restaurantes, el nombre debe de ser RestauranteController, ademas debe de derivarse de la base base System.Web.MVC.Controller.
Por lo tanto cuando naveguemos hacia el URL /Restaurante/, este será manejado por el controlador restaurante. Cada controlador responde a un grupo de acciones definidas para él, mediante métodos públicos, por lo tanto si deseamos que nuestro controlador realice una acción nuestra URL debe de ser /Restaurante/Menu, en donde menu es la acción a ejecutar.
Nuestras acciones pueden recibir parámetros, cuyos valores pueden provenir, por ejemplo de una forma HTML, si nuestro método solo recibe un parámetro, por ejemplo de tipo entero, la URL para nuestra acción se vería así: /Restaurante/Menu/1, donde 1 es el parámetro entero que acepta nuestra acción; si la acción acepta mas de un parámetro, la forma en como estos se representaran en nuestra URL es de la siguiente forma: /Restaurante/Menu/1?parametro2=34; donde parametro2 es el nombre de nuestro segundo parámetro cuyo valor es 34.
public class RestauranteController : Controller
{
public ActionResult Index()
{
return View();
}
public ActionResult Menu(int restaurante)
{
return View();
}
}
Algo importante a notar en la definición de nuestras acciones realmente son funciones que regresan el tipo ActionResult, este es un tipo especial que en nuestro caso cuando se ejecuta la instrucción return View(), sucede que la vista es cargada y ejecutada para producir el código HTML que va a ser presentado en el navegador Web.
El ruteo
Como se vio el ASP.NET MVC hace uso de ciertas convenciones para realizar su trabajo, una de estas convecciones esta relacionada en como la URL es interpretada para luego ser enviada al controlador/accion correcta.
El manejo de la URL proviene de una tabla de rutas con las cuales se define como la URL va a trabajar en nuestra aplicación, la convención por omisión estable que la URL va a ser interpretada como: [controlador]/[accion]/[parametro], pero no es posible cambiarla de manera que se ajuste mejor a nuestras necesidades.
La configuración de ruteo se encuentra en el archivo Global.asax de nuestro proyecto, ahí vamos a encontrar el método RegisterRoutes, el cual tiene definida la manera por omisión en como nuestra aplicación va a interpretar las URL que el usuario navegue.
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = "" } // Parameter defaults
);
}
Esta ruta especifica lo que hemos venido observando en nuestra aplicación, que la primera parte de nuestra URL corresponde al controlador, la segunda parte indica la acción a ejecutar y la tercera parte pertenece a los parámetros.
También especifica que si recibimos una URL sin parámetros, nuestro parámetro va a ser nulo, si la URL no cuenta con la acción a ejecutar, entonces se llamara la acción Index de nuestro controlador, por lo tanto es importante tener una acción Index; finalmente también indica que si no especificamos el controlador, entonces la petición se dirigirá al controlador Home con la acción Index.
En esta sección de nuestro programa podemos agregar nuevas rutas con diferentes características que satisfagan nuestras necesidades, solo hay que tener en cuenta que las rutas son evaluadas en el orden que se registran.
VistasLas vistas en nuestra aplicación de MVC se encuentran en el directorio /Views, dentro de este directorio existe una sub-estructura de directorios, que una vez mas, obedecen a una convención de nombres sobre la cual funciona el framework.
Dentro del directorio /Views encontramos un directorio Shared, el cual contiene un archivo de Master Pages, Site.master, este archivo es la plantilla HTML que nuestra aplicación va a utilizar, la naturaleza de este archivo es proveer de una interface unificada en toda la aplicación. Esta plantilla global cuenta con una sección la cual funciona como un contenedor, el cual va a ser llenado con el HTML generado por nuestras vistas.
Este archivo Site.master debe de contener un tag:
<asp:ContentPlaceHolder ID="MainContent" runat="server" />
Con el cual indicamos que en esa sección es donde deseamos que el contenido generado por nuestra vista se despliegue, así que si creamos una plantilla maestra, hay que recordar agregar ese tag.
Volviendo al contenido de nuestro directorio /View, también encontramos un folder por cada uno de los controladores de nuestra aplicación, y cada uno de estos folders tienen por nombre el mismo nombre del controlador al que pertenecen.
Dentro de cada folder con nombre de controlador vamos a encontrar archivos cuyo nombre corresponden a las acciones de nuestro controlador, los archivos tienen la extensión .aspx, lo cual nos indica que que son archivos de ASP.NET, pero estos archivos en realidad son plantillas MVC.
La gran diferencia es que las vistas MVC en ASP.NET MVC no contienen controles ASP.NET, sino controles HTML, aunque dentro de las plantillas colocamos código en C# o VB.NET dentro de los tags <% %>, este código corresponde a lo que se conoce como "Ayudantes de HTML" (HTML Helpers), los cuales son implementados como métodos de extensión (Extension Methods) y cuya finalidad es que al momento que nuestra vista es evaluada para enviar el código HTML a cliente, los ayudantes de html generen el código HTML apropiado.
Loas ayudantes de HTML predefinidos nos permiten crear una gran variedad de objetos HTML, por ejemplo si deseamos agregar una liga dentro de nuestra vista, el código del ayudante que realizaría esta acción es:
<%= Html.ActionLink("Comprar", "Comprar", new {id = 1}) %>
Este código va a generar la siguiente liga en HTML:
<a href="/Restaurante/Comprar/1">Comprar</a>
El primer parámetro de Html.ActionLink es el texto que se va a desplegar con la liga, el segundo es la acción del controlador a la cual la liga nos va a enviar y finalmente pasamos un parámetro para nuestra acción, en este caso el valor entero 1.
Existe un mecanismo mediante el cual podemos enviar desde el controlador la información gestionada con el modelo a la vista, para tal efecto tenemos un objeto de tipo Dictionary < string, object > llamado ViewData al cual podemos hacer referencia desde el controlador y desde la vista.
Por ejemplo si deseamos enviar información a nuestra vista, podemos usar el objeto ViewData de la siguiente forma:
ViewData["MiLlave"] = "Mensaje a desplegar en la vista";
"MiLlave" representa el identificador dentro del objeto diccionario con el cual vamos a poder acceder al dato guardado, por ejemplo si queremos imprimir ese mensaje en nuestra vista, lo podemos hacer de la siguiente manera:
<% Html.Encode(ViewData["MiLlave"]) %>
El objeto ViewData tiene una propiedad que es especifica para pasar la información de nuestro modelo a la vista, esta propiedad es Model, por ejemplo para pasar el objeto mimodelo a la vista lo hacemos así:
ViewData.Model = mimodelo;
Para acceder al modelo desde la vista lo hacemos de la siguiente forma:
<% Html.Encode(ViewData.Model.Dato) %>
Aquí asumimos que el objeto mimodelo tiene una propiedad llamada Dato, que es la que nuestra vista despliega.
ModeloEl modelo en una aplicación representa a los datos con los cuales la aplicación va trabajar. El modelo se compone de un grupo de clases que sirven para representar un dominio de información, la información puede provenir de diferentes fuentes como base de datos relacionales, archivos de texto, servicios REST.
De igual forma el modelo puede administrado por diferentes tecnologías, técnicas o patrones, tal y como se describió en el post "ActiveRecord".
Para el caso de la aplicación que se vio durante este curso, nuestro modelo esta implementado con el patrón ActiveRecord y específicamente con las librerías Castle ActiveRecord.
Par tal motivo esta sección se va a destinar a indicar como habilitar Castle ActiveRecord para que funcione con el ASP.NET MVC.
El primer paso va a ser agregar las referencias necesarias a nuestro proyecto MVC. Primeramente necesitamos referencias las librerías NHibernate.dll y Castle.ActiveRecord.dll, posteriormente agregamos la referencia a nuestra librería que contiene nuestros modelos de ActiveRecord, esta librería es ITT.ParaLlevar.Model.
Nuestro siguiente paso es agregar al archivo Web.config la configuración de ActiveRecord, dentro de la sección < configSection/ > agregamos la siguiente configuración:
<section name="activeRecord" type="Castle.ActiveRecord.Framework.Config.ActiveRecordSectionHandler,
Castle.ActiveRecord"/>
Dentro del mismo Web.config dentro de la sección < configuration/ > agregamos las siguientes lineas que configuran ActiveRecord con nuestra base de datos relacionales, hay que recordar modificar la cadena de conexión para que refleje el nombre de nuestro servidor:
<activeRecord isWeb="true">
<config>
<add key="hibernate.connection.driver class"
value="NHibernate.Driver.SqlClientDriver"/>
<add key="hibernate.dialect"
value="NHibernate.Dialect.MsSql2000Dialect"/>
<add key="hibernate.connection.provider"
value="NHibernate.Connection.DriverConnectionProvider"/>
<add key="hibernate.connection.connection_string"
value="Data Source=SERVIDOR;Initial Catalog=ParaLlevar;Integrated Security=True"/>
</config>
</activeRecord>
Esta configuración es exactamente la misma que la configuración que teníamos en nuestro archivo AR.cfg.xml de la aplicación de Windows.Forms, el único cambio es que en el tag < activeRecord > agregamos la propiedad isWeb="true".
Ahora debemos inicializar ActiveRecord dentro de nuestra aplicación, por lo tanto nos vamos a dirigir al archivo Global.asax, ahí buscamos el metodo Application_Start() y agregamos las siguientes lineas:
var source = System.Configuration.ConfigurationManager.GetSection("activeRecord") as Castle.ActiveRecord.Framework.IConfigurationSource;
Castle.ActiveRecord.ActiveRecordStarter.Initialize(typeof(Restaurante).Assembly, source);
Y con esto estamos listos, podemos regresar y completar nuestro controlador Restaurante para que gestione información del modelo y la pase a la vista, nuestro controlador completo quedaría como sigue:
public class RestauranteController : Controller
{
public ActionResult Index()
{
var restaurantes = Restaurante.FindAll();
ViewData.Model = restaurantes;
return View();
}
public ActionResult Menu(int id)
{
var restaurante = Restaurante.GetById(id);
ViewData.Model = new RestauranteData {Restaurante = restaurante};
return View();
}
public ActionResult Comprar(int id)
{
return View();
}
}
Ahí podemos ver claramente como nuestro controlador gestiona la información, la pasa a través del objeto ViewData y su propiedad Model, para finalmente con return View() llama la vista apropiada para su evaluación. Nuestra vista para la acción Index() se vería así:
<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" AutoEventWireup="true" CodeBehind="Index.aspx.cs" Inherits="ITT.ParaLlevar.Web.Views.Restaurante.Index" %>
<%@ Import Namespace="ITT.ParaLlevar.Model"%>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" runat="server">
<ul>
<% foreach (var restaurante in (ViewData.Model as Restaurante[])) { %>
<li>
<%= Html.ActionLink(restaurante.Nombre, "Menu", new { id = restaurante.Id })%>
</li>
<%} %>
</ul>
</asp:Content>
Lo que nos da como resultado una lista con los restaurantes registrados en nuestra base de datos.
ConclusiónComo mencione casi al principio de este post, tanto este como el post de ActiveRecord hablan sobre patrones establecidos en la industria para resolver problemas recurrentes, ambos post son parte del curso donde se discutió con un poco mas de detalle cada uno de los temas.
En ambos posts se omitieron algunos detalles de la implementación debido al tiempo y a la longitud de las mismo. El código fuente que acompaña ambos posts, no representa una aplicación completa, mas bien ilustra los puntos a resaltar.
Aunque los post estuvieron centrados sobre Castle ActiveRecord y ASP.NET MVC, el conocimiento de ambos patrones es ampliamente utilizados en diferentes lenguajes/tecnologias, por lo tanto el conocimiento no se limita a estos dos frameworks.
Referencias
Como cada año la revista 
Si eres mujer y trabajas en IT en promedio vas a ganar 6,000 pesos mensuales menos que los hombres.
Según las conclusiones del articulo, los salarios IT en México crecieron un 13% con respecto al 2007. Las posiciones administrativas son las que mas ganan, con la excepción del Arquitecto de Sistemas que es muy remunerada a pesar de ser muy técnica.
