ASP.NET MVC Series

Acá tenemos la lista de posts de la serie ASP.NET MVC y otras Yerbas

• Parte 1.- DDD (Domain Driven Design)
• Parte 2.- Unit Testing and TDD (Test Driven Development)
• Parte 3.- TDD: Kata Prime Factors
• Parte 4.- Domain Services and Repositories
• Parte 5.- Controllers and ViewModels
• Parte 6.- Bootstrap MVC with IOC (Inversion of Control)
• Parte 7.- Configure NHibernate

Saludos.

ASP.NET MVC y otras Yerbas – Parte 6

Es hora de hablar sobre “Inversion of Control”:

El Problema

Qué observamos en el código anterior:

• La clase SmtpClient está directamente referenciada por la clase HomeController y está última controla su creación, lo que tiene como consecuencia un fuerte acoplamiento entre estas dos clases.
• La clase HomeController es consciente de la clase SmtClient y su funcionamiento, por lo tanto si alguna vez tenemos que realizar algún cambio sobre el envió de correo: como enviarlo por una cola de mensajes o incluso cambiar por una nueva librería, la clase HomeController se verá afectada.
• Se dificulta la realización de pruebas sobre la clase HomeController.

La Solución

Si somos capaces de cambiar el control de la creación de la clase SmtpClient a una tercera entidad, podremos ver resuelto nuestro problema. Y esa solución es: Inversion of Control.

Inversion of Control

“Is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to traditional architecture of software”
Wikipedia

Podemos implementar este patrón de 2 maneras distintas:

Dependency Inyeccion

La idea es tener un objeto en el “mundo exterior” que se encargue de proveer o inyectar la implementación adecuada (EmailSender) a la clase listener (HomeController)

Service Locator

La idea es tener una entidad “dentro de la clase” que conozca cómo obtener la implementación adecuada que esta clase podría necesitar.

Ahora veamos cómo estas cosas se utilizan en nuestra aplicación de ejemplo y adicionalmente veremos como podemos configurarla para que levante y ejecute.

También podemos verlo en HD

No se olviden de ver el resto de la serie ASP.NET MVC y otras Yerbas.
Hasta el siguiente post.
Saludos

ASP.NET MVC y otras Yerbas – Parte 5

Le llego el turno al Controlador y al Modelo ViewModel.

Para una mejor calidad también podemos verlo en HD.

Controlador.- Es el encargado de recibir y manejar las peticiones realizadas por los usuarios, y mostrar la vista adecuada.

ViewModel.- Es aquí donde viene el dilema. Comúnmente existe el problema en decidir cuál es la “M” dentro de nuestro modelo MVC. Es una entidad ?, un DTO ? , algo más ?.

Para algunos la “M” se refiere a una clase que ha sido diseñada para satisfacer las necesidades específicas de una vista en particular - “ViewModel”. Pero cuales son las razones que nos llevan a optar en utilizar una nueva clase únicamente para una vista, ya que esto supone un mayor esfuerzo (aparentemente):

• A medida que las vistas se vuelven más complicadas es difícil mantener una sincronización entre las clases del dominio y las necesidades de la vista. Imaginemos una vista con un wizard que envía información sobre el paso al cual quiere ir el usuario, definitivamente no vamos a querer agregar esa información a una entidad del dominio ya que es únicamente de interés de la vista.

• Muchas veces escribimos lógica innecesaria dentro de una vista, esto se puede representar en algo tan simple como: Html.Hidden(“id”,Model!=null?Model.ID:0) .Debido a que las vistas son difíciles de probar es recomendable mover esta lógica a otra clase que facilite esta tarea.

• Al utilizar las entidades como “Model”, la vista tendrá conocimiento detallado de parte de dominio, lo cual para algunos puede significar que se daña de cierta manera la estructura y la arquitectura de la aplicación. Creo que esto no es más que otra decisión de diseño y esto lo podemos ver en varias aplicaciones antiguas, en especial aquellas que tienen a la base de datos relacional como centro de la aplicación y utilizan a las “entidades” como simples transmisores de datos. Después de vivir tantos años con estas aplicaciones podemos decir que las bases de datos relacionales no lo son todo en esta vida.

Los siguientes links tienen bastante información de los patrones que podemos utilizar para diseñar un ViewModel y las ventajas y desventajas de estos.

http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx
http://blogs.msdn.com/simonince/archive/2010/01/26/view-models-in-asp-net-mvc.aspx

No se olviden de ver el resto de las serie ASP.NET MVC y otras Yerbas.
Hasta el siguiente post.
Saludos.