El otro día, torpe de mi, estaba migrando una aplicación IIS6 a otra IIS7. Todo parecía marchar bien, a excepción del lazy-loading fuera de los límites de los métodos transaccionales… es decir, en la vista (si, se que es controvertido pasar entidades a la vista… pero mire usted, la vida es dura y no todo es como a uno le gustaría

El caso es que en IIS6 y en el servidor embebido de Visual Studio, la cosa iba perfectamente… pero en el IIS 7.5 no había manera. Entonces sonó la flauta en mi cabeza… cambié la configuración del AppPool de integrated pipeline a classic pipeline y bingo, a funcionar! Pero, obviamente, la idea es olvidarse del doble pipeline de peticiones IIS+filtro isapi, y para eso está el integrated pipeline…

Lo que ocurrió fue que “se me olvidó” que en el integrated pipeline, la sección system.web/httpModules del web.config pinta poco, y hay que mover (o copiar, si quieres que vaya en cualquier entorno) los módulos ahí declarados desde system.web/httpModules a system.webServer/modules… entre ellos, el OSIV, el loader de spring… Una vez hecho eso, el integrated y todas sus ventajas se volvieron a llevar bien con el OSIV de Spring.NET+NHibernate.

El integrated pipeline tiene otras sorpresas, como la imposibilidad de hacer, de forma natural, que haya una doble autenticación “básica” http + forms (bastante común en entornos de preproducción, “pruebas” de cliente, aceptaciones de maquetas…) Para esto he estado pensando soluciones y, la verdad la verdad, veo pocas que me gusten (que me gusten = que no involucren cambiar el código, dado que éste debe ser el mismo en desarrollo/integración que en producción, y en producción no existirá este problema…)

La inyección de dependencias es uno de esos patrones que realmente hay que usar en cualquier proyecto no trivial. En .NET está muy de moda Castle Windsor y algún otro contenedor ligero… pero yo estoy bastante cómodo (de momento, no descarto nada) con Spring.NET. A la hora de integrar Spring.NET con ASP.NET MVC, eché un vistazo a google y nada de lo que ví me convenció realmente (igual no busqué demasiado), así que decidí hacermelo yo.

Aprovechando la facilidad para extender el framework, en el global.asax.cs metemos una línea como esta:

1
2

// ControllerBuilder, para que se inyecten los controladores.
ControllerBuilder.Current.SetControllerFactory(new Arc.Web.Mvc.SpringControllerFactory());

y creamos la clase (Arc.Web.Mvc.SpringControllerFactory) tal que así:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

namespace Arc.Web.Mvc
{
 public class SpringControllerFactory : DefaultControllerFactory, IControllerFactory
 {
 #region IControllerFactory Members
 
 public IController CreateController(System.Web.Routing.RequestContext requestContext, string controllerName)
 {
 // Probado y funciona!
 IController ctrl = base.CreateController(requestContext, controllerName);
 if(ctrl!=null)
 {
 IApplicationContext ctx = ContextRegistry.GetContext();
 string objectName = controllerName + "Controller";
 if (ctx.ContainsObjectDefinition(objectName))
 {
 ctrl = (IController)ctx.ConfigureObject(ctrl, objectName);
 }
 }
 return ctrl;
 }
 
 #endregion
 }
}

Luego solo necesitamos definir los controllers en el application-context de spring como cualquier otro objeto:

 <object name="AccountController" type="W.Web.Public.Controllers.AccountController, W.Web.Public" autowire="byName" singleton="false"/>

Y ya está

Llevo unas semanas tocando ASP.NET MVC, y me gustaría comentar que es un buen framework para hacer sitios Web. Sin embargo, creo que le queda un gran camino para ser útil en aplicaciones Web. Para mi, son cosas radicalmente distintas en el 95% de los casos. Hay casos en los que está más difuso, pero son pocos.
El caso es que ASP.NET MVC es bueno. Abraza el modelo stateless inherente al HTTP. Abraza también el modelo de recursos “localizables” mediante identificadores uniformes URL. ASP.NET WebForms se olvidaba de todo esto y montaba una capa de abstracción orientada a eventos y componentes, tan potente como peligrosa e inadecuada para según qué proyectos.

ASP.NET MVC tiene fallos, que se pueden solucionar en su mayoría dada su plugabilidad (toma palabro), o que se están subsanando en la versión 2 que vendrá con .NET 4.0 y VS2010 – versión de la que ya hay previews y que parece ser muy interesante.

Cosas que no me gustan de ASP.NET:

• Los helpers no tipados especialmente. Son simples y no requieren saber usar expresiones, pero asimismo son peligrosos, un punto de fallo común que aumenta alarmantemente el número de roundrips si te equivocas cuando programas. Es algo común en la versión 1.0 del framework que parece que se subsana en la 2, el hecho de trabajar a menudo con strings en vez de con expresiones C#… también baja un poco el punto de entrada, no todo el mundo entiende lo que es x => x.Nombre.
• Los helpers como concepto… son de demasiado bajo-nivel. Debería ser posible cierta composición, cierta componentización. Eso si, absolutamente stateless, con un estado plugable y un binding basado en expresiones (expresiones C# o en algún lenguaje de EL como las de WPF). A lo mejor, un modelo más declarativo no estaría mal.
• La ausencia del concepto de ciclo de vida de estado (si nos olvidamos del ModelState, con un comportamiento digamos… mágico). Entiendo que se ha dejado fuera debido a que es un “concern” distinto y a que no todo el mundo sabe lo que es ni lo necesita… pero trabajar sin esto supone trabajar a un bajo nivel que únicamente me resulta aceptable en sitios Web o proyectos sencillos, nunca en aplicaciones complejas con elevado número de interacciones sobre un modelo.
  Desde que el señor King, con Seam, extendiera el concepto de conversaciones en los entornos Web, se me hace dificil pensar en una aplicación Web server-side compleja sin esta característica (la otra opción son clientes ricos y servers REST simples y stateless, que tampoco es mala).
• Los bindings son buenos, pero no son excelentes. Algo absolutamente subsanable dado lo plugable que es el framework… pero vamos, hacer un defaultModelBinder que tenga en cuenta que te vayan a venir identificadores de entidades y que de algún sitio se van a tener que sacar… es un caso de uso común al 99′999% de las aplicaciones que trabajan con ORMs, y debería habérsele dado cierta cobertura. Los señores de S#arp lo han resuelto de una manera aceptable, y con sus ideas y un poco de cinta aislante, esta parte se “sujeta” y permite olvidarse de tener controladores repletos de User.Country = Repository.Get<Country>(countryId);, además de permitir participar a las entidades en las validaciones ( y esto supone tener disponible el grafo entero de objetos en la validación… yummy!).
• ASP.NET tiene mucha herencia de WebForms, y hay mezclado mucho de WebForms en él. Creo que se debería refactorizar el Framework para separar bien el modelo de componentes y eventos de WebForms, sus validaciones, su ciclo de vida y sus requerimientos, sobre el bajo-nivel de peticiones HTTP, que es lo único que necesita ASP.NET MVC.
• La capa de vista ASP.NET, a veces es un poco ortopédica. Los sres. de MS deberían trabajar en proporcionar una capa de vista más declarativa (algo parecido a lo que da WPF). Esto ayudaría mucho también a trabajar en un modelo de componentes visuales (de nuevo, por favor, stateles o con estado plug’able).
• El hecho de que MVC sea System.Web.MVC y no System.MVC. Un MVC real no dependería de la web. En este caso, estamos hablando de un MVC streamlined para web totalmente, sin ninguna aspiración de permitir la construcción de aplicaciones con MVC sobre otros entornos.
• El hecho de que sólo vaya en Windows ). Está claro que Windows, a pesar de las mejoras, no es el mejor sistema operativo para sitios Web, le duela a quién le duela. Ha mejorado muchísimo y es digno de consideración, pero esto es una realidad y hay que aceptarla cuando se trabaja en este entorno, teniendo en cuenta que nunca vas a tirar tantas req’s estáticas por segundo como los servidores ligeros sobre unix/linux, o que no vas a tener la misma flexibilidad que en un apache para hacer diabluras. Un entorno Windows de servidor idealmente debería estar protegido por algún acelerador o SoftADC’s como los llaman ahora (Zeus LB?, Varnish?), y apoyado por servidores unix/linux en aquellas tareas en las que no es demasiado bueno (DNS, BD’s no-sql-server… y especialmente, correo electrónico). Por supuesto, tendrá delante firewalls y una configuración bien restringida para que no de sustos (y aun así…).

Cosas buenas:

• En un proyecto en el que hay diseñadores por un lado y programadores por otro, la sintonía es mucho mayor que con WebForms, el código de un diseñador / maquetador fluye naturalmente en las vistas de ASP.NET, permitiendo un HTML semánticamente bonito y estructuralmente correcto y fácil de entender y depurar.
• El rendimiento, al adelgazar ASP.NET de toda su grasa (jerarquía de componentes, viewstate)… es excepcionalmente elevado, al nivel de los mejores frameworks java y muy por encima de ASP, PHP y especialmente de – le duela a quién le duela – Ruby on Rails. El CLR de MS es bueno, no es la JVM pero es bueno, mucho más rápido que el motorcillo VbScript de ASP, que el Zend Engine de PHP o que la vetusa máquina virtual de ruby-C (o la capa de grasa a alto nivel que supone JRuby sobre la JVM).
• El desarrollo de sitios Web es rápido. No así el de aplicaciones Web, pero menos da una piedra… el caso es que no va mal. VS2008 es un buen entorno para codificar y depurar, y ASP.NET MVC es amigable al desarrollador, y normalmente proporciona una experiencia de desarrollo sin demasiadas fricciones.
• La comunidad es creciente. ASP.NET MVC proporciona muchas de las ventajas de Ruby on Rails, Django y Cake (los new-kid-on-the-block de los que tanto se ha escrito en los últimos 2-3 años) en un entorno muy aceptado a nivel empresarial.

That’s all, a ver que trae la próxima Preview de la versión 2!