Quienes hayan trabajado alguna vez con .Net, conocerán el sistema de plantillas de ASP.Net llamado webforms. Los webforms fueron un sistema de vistas con extensión aspx que podían ir o no acompañadas de un codebehind y controles. El objetivo de Microsoft cuando diseño esta parte del framework de .Net fue mover a los desarrolladores a crear aplicaciones en nube, que aunque ahora este tan de moda el termino nube, estamos en un contexto del año 2000. Los webforms permitían desarrollar una web, tal y como los desarrolladores del viejo Visual Basic hacían sus aplicaciones de escritorio, donde las páginas eran llamadas formularios (de ahí el término webform) y los elementos tales como inputs, botones, etc, se arrastraban con un editor wysiwyg. Los antiguos webforms, aunque simulaban un entorno de escritorio, en cuanto a formularios, no eran otra cosa que webs y como tales podías tocar el html desde el editor y no solo tener la opción de editor wysiwyg, encontrando bajo el capo una web de código espagueti tal y como siempre se habló de php por ejemplo, salvo que parte de la lógica estaba en el codebehind. Esta última parte era lo peor de todo, puesto que si el desarrollador era experto, el código espagueti era minúsculo, pero a medida que descendía la pericia del programador, aumentaba el tamaño tanto del codebehind como del propio espagueti html que era ese aspx webform.

Microsoft publico todo esto en las primeras versiones del .Net framework y fue un bombazo, cualquiera podía hacer una web con muchos formularios en un tris, pero claro, ahí esta está el cliente para recordarnos que era muy feo y que lo querían mas bonito como habían visto por internet otras páginas. Es entonces cuando empiezan a verse los primeros problemas a la hora de realizar webs y es que aspnet 1 no tenia soporte para páginas maestras, por lo que los desarrolladores acababan en practicas comunes en otros lenguajes y que eran tan criticadas como copiar y pegar la misma estructura de página (controles, cabecera, menu, pie, etc) por todas y cada una de las páginas que tuviéramos en nuestro proyecto. Así que como novedad, Microsoft pensó que aparte de cambiar la forma de incluir los controles en una web, automatizando todo el proceso, penso que era hora de crear un concepto mas que necesario, una masterpage. Una masterpage, no es mas que como su nombre indica, una página maestra, digamos que todo ese contexto de cabeceras, menu, pie, etc que ibamos copiando de página a página pero que ahora se centraliza en un sitio, marcando en esa página maestra, donde queremos que se renderice el contenido de la página. Esto supuso un gran avance, ya que las páginas desarrolladas con ASP.Net, fueron mejorando en el punto que eran mas limpias. Aun y con todo, seguian los problemas, el auge de librerías de javascript dinámicas, con efectos y llamadas de ajax, dejaba en ridículo a controles muy cerrados tipo updatepanels y los desarrolladores pedían a gritos mas flexibilidad.

Cuando uno ha vivido toda la vida amamantado por la teta de Microsoft, no se percata de cierta rigidez a la hora de desarrollar una web con ASP.Net, pero quien tocara cualquier otro entorno, veia como en php y python, aparecian framework MVC, que permitian utilizar todas esas librerias de ajax pero sin montar un pipote (caos) de código para que funcionen bien. Es entonces cuando aparece MVC. El concepto de MVC es un concepto creado en 1979, no trae ninguna novedad como tal, pero si que introduce ese concepto en ASP.Net teniendo una serie de caracteristicas fundamentales (en un sistema normal sin mucha floritura):

• Los controladores son siempre los que reciben las peticiones, ya no hay controladores genéricos ashx, servicios asmx, paginas aspx, controles ascx, ni masterpages master. Los controles son clases donde por defecto, sus métodos serán aciones del controlador.
• Las vistas son solo eso, vistas, con sintaxis webform en MVC 1 y 2 y con Razor en MVC 3 y 4.
• Los modelos son clases con propiedades multifunción, validar automáticamente datos, enviar y recibir formularios, sincronizar datos con la base de datos (Entity Framework Code First).
• El proyecto es un binario cerrado, como ocurría en la primera versión de ASP.Net y en el resto si lo cambiabas a proposito, ya no hay mas código abierto con el que dejar a IIS que compile el código, como si fuera php.

Hasta aquí, una breve explicación de como surge MVC, pero ¿Y Razor? Razor es el nuevo sistema de templates de ASP.Net MVC. Quien haya programado con webforms, se habrá dado cuenta que en una página con un poco de lógica, acaba creciendo mucho y complicando la sintaxis con abre código <%, mete código, cierra código %>, haciendo que no solo crezca una página, sino que además, el código se vuelve mas y mas feo por momentos. Razor soluciona esto con 2 procedimientos, el primero es su cierre automático inteligente, es decir, la etiqueta de apertura será una arroba @, pero no tendrá cierre como tal. La segunda peculiaridad es que el código es mucho mas fluido puesto que se aprovecha del propio html para formar ciertas partes de la sintaxis. Ademas, Razor tiene algunas ventajas como son poder indicar un modelo que utiliza la página para hacer validaciones, formularios y pintar datos de una forma mas sencilla.

Veamos un par de ejemplos de código hecho con Razor frente al hecho con webform:

@model Indacalsa.Models.LoginModel

@using (Html.BeginForm("Login", "Account", FormMethod.Post)) {
  @Html.AntiForgeryToken()
  <fieldset id="login">
    <legend>Datos de acceso @ViewBag.Title</legend>
    <p>
      <label>
        <span class="title">Usuario:</span>
        @Html.TextBoxFor(m => m.UserName)
        @Html.ValidationMessageFor(m => m.UserName)
      </label>
    </p>
    <p class="center">
        <input type="submit" value="Acceder" class="btn" />
    </p>
  </fieldset>
}

<form method="post" action="/Login/Account.aspx" runat="server">
  <fieldset id="login">
    <legend>Datos de acceso <%=this.Title%></legend>
    <p>
      <label>
        <span class="title">Usuario:</span>
        <asp:TextBox name="UserName" id="UserName" runat="server" />
        <asp:RegularExpressionValidator ID="validatorUserName" runat="server" ControlToValidate="UserName" ErrorMessage="La longitud mínima es de 5 caracteres" ValidationExpression=".{5}.*" />
      </label>
    </p>
    <p class="center">
        <asp:Button value="Acceder" class="btn" runat="server" />
    </p>
  </fieldset>
</form>

Lo he simplificado, primero en Razor y luego en ASP.Net webforms. La parte de webforms la he simplificado sin utilizar el tipico form que ocupa toda la página y sin mucha historia, para dar un acercamiento de como va el tema. Aparte de este ejemplo hay que sacar la mala experiencia de utilizar controles de webform y sus ids mágicos, si es que luego queremos dinamizar la página con ajax o javascript.

Y para los que vengan de atras, aquí van algunas similitudes entre webform y Razor:

• Las masterpage de webform ahora son llamadas Layouts
• Los controles de webform ahora son vistas parciales, pero con la salvedad de que no tendrán codebehind.
• Para especificar código espagueti o en linea en webforms se hace con <% codigo %> y <%=codigo%>. Con Razor se hace con @micodigo o @(micodigo_muy_complejo).
• Para ir renderizando texto dentro del código de Razor ya no es necesario abrir y cerrar las etiquetas de codigo <% y %>, sino que podemos usar <text>texto a renderizar</text>
• Los asp:content de las masterpages ahora son sections.

Espero que os guste y os sirva un poco a aquellos rehacios a migrar a MVC o desde otros lenguajes.