aelena.com

Con las sucesivas versiones del MVC para asp.net que vienen apareciendo desde Octubre del 2007, el equipo de Scott Guthrie nos ofrece un framework que trasciende el modelo de eventos al que estamos acostumbrados, y nos ofrece varias ventajas nuevas, que para ser aprovechadas nos obliga a cambiar el modo de desarrollar habitual de asp.net.

No obstante, las ventajas son muchas:

• Separación clara de dónde tiene que ir cada tipo de lógica (separation of concerns). Esto nos facilita el mantenimiento y la escalabilidad de la aplicación, además de facilitar el desarrollo en paralelo de las distintas partes o módulos.
• Suporte al desarrollos por medio de metodología TDD por defecto (Test Driven Development). Por tanto facilidad para crear mock  tests y para poder correr los tests desde fuera del proceso de asp.net. Gran diferencia con respecto a como se tenían que hacer las pruebas anteriormente, o bien a mano, o bien con torpes y complejas macros para disparar eventos en la interfaz.
• Arquitectura “pluggable” y extensible, en la que los componentes pueden ser aumentados o extendidos, algo que ya se podía hacer en las versiones anteriores de asp.net, pero que ahora va más allá. Ahora podemos usar inyectores de dependencia como Castle Windsor, Spring.net o Unity.
• Motor de routing (asociación de una URL concreta con el controller correcto) para tener url más legibles, al estilo REST.
• No hay ViewState ni ciclo de vida de las páginas. Menos peso, menos complejidad.
• Control total del HTML generado. No tenemos controles que añaden su propio markup. Esto nos permite ademas integrar más fácilmente librerías como JQuery o MooTools, y olvidarnos de todo el código que asp.net inyecta para el mantenimiento del estado y el ViewState.

Conviene recordar que MVC no suplanta o elimina el desarrollo “tradicional” mediante webforms. Se trata simplemente de una alternativa que hay que sopesar según la situación y el tipo de proyecto. No olvidemos que asp.net webforms nos ofrece también un modelo de eventos familiar a todos los desarrolladores, mantenimiento del estado entre requests, numerosos controles de otros vendedores. No se trata de despreciar ahora este estupendo modelo de desarrollo.

Es necesario, por tanto, escoger el modelo en cada caso. Asp.Net MVC nos viene bien, o no, si queremos

• Desarrollar según TDD.
• Necesitamos controlar el HTML generado completamente.
• Operaciones atómicas que no necesitan estado entre peticiones. Si la aplicación es muy orientada a datos y necesitamos estado, no es la opción adecuada.
• Podemos prescindir de los eventos o sustituirlos mediante javascript y invocaciones web via ajax.
• No es la opción adecuada si tenemos que usar controles ya generados o crear prototipos rápidos mediante drag & drop. Para eso, mejor webforms.

La gente de Pluralsight, entre los que están expertos reconocidos como Aaron Skonnard, nos dejan hoy una serie de artículos introductorios pero interesantes, que podeis descargar aquí. Los artículos en cuestión son:

• An Introduction to Microsoft .NET Services for Developers (Aaron Skonnard)
• A Developer’s Guide to the Microsoft® .NET Access Control Service (Keith Brown)
• A Developer’s Guide to the Microsoft® .NET Service Bus (Aaron Skonnard)
• A Developer’s Guide to the Microsoft® .NET Workflow Service (Matt Milner)

Hay otro link de descarga directa aquí.

Si te enseñan el siguiente código, ¿cuál crees que es el resultado?

   1:  struct MutableStruct

   2:  {

   3:      private int x;

   4:      public int Mutate ( )

   5:      {

   6:          return ++x;

   7:      }

   8:  }

   9:  

  10:  class Program

  11:  {

  12:  public readonly MutableStruct _ms = new MutableStruct ();

  13:  static void Main ( string [] args )

  14:  {

  15:  Program _p = new Program ();

  16:  Console.WriteLine ( “Valor de la copia: {0} “,

  17:  _p._ms.Mutate ());

  18:  Console.WriteLine ( “Valor de la copia: {0} “,

  19:  _p._ms.Mutate () );

  20:  Console.WriteLine ( “Valor de la copia: {0} “,

  21:  _p._ms.Mutate ( ));

  22:  Console.ReadLine ();

  23:  }

  24:  }

El resultado puede sorprendernos a muchos. En realidad, no es 0, 0, 0 ni 1, 2, 3 sino 1,1,1. ¿Porqué? ¿cómo es eso? La cosa reside en la propia especificación del lenguaje C#. Recordemos que las struct son tipos de valor (value types), no referencias, es decir, son como un int y no como un objeto, como por ejemplo string. Por tanto, su valor no puede cambiar. Lo que ocurre es que al acceder a la struct en el código, obtenemos una copia de dicho valor, que no una referencia como ocurriría si accedieramos a un objeto, a una instancia de la clase “Producto”, por ejemplo, en nuestra aplicación. Es decir, que al hacer _p.ms estamos obteniendo una copia, y esa copia si es mutable, mientras que _m no lo es. Si modificamos el código ahora para comparar el valor original y la copia lo veremos más claro:

struct MutableStruct
{
private int x;
public int Mutate ( )
{
return ++x;
}
public override string ToString ( )
{
return String.Format ( “Valor de x: {0}”, x );
}

}

class Program
{
public readonly MutableStruct _ms = new MutableStruct ();
static void Main ( string [] args )
{
Program _p = new Program ();
Console.WriteLine ( “Valor de la copia: {0},{1}”,
_p._ms.Mutate (), _p._ms.ToString () );
Console.WriteLine ( “Valor de la copia: {0},{1}”,
_p._ms.Mutate (), _p._ms.ToString () );
Console.WriteLine ( “Valor de la copia: {0},{1}”,
_p._ms.Mutate ( ), _p._ms.ToString () );
Console.ReadLine ();
}
}