ASP.NET Core paso a paso – Introducción

Es momento de empezar a hablar de ASP.NET Core, por lo que este es el primer post de una serie denominada “ASP.NET Core paso a paso” – bien Mostaza Merlo – en donde vamos a ir viendo en detalle las distintas características del mismo.

En esta primer entrega vamos a comentar de que se trata este framework y cuales son sus principales características. Luego, a partir de las siguientes entradas ya vamos a meternos en cuestiones técnicamente más puntuales.

Sigue leyendo

Anuncios

ASP.NET MVC Pipeline: Routing

Hace ya un tiempo que no escribo sobre el “tradicional” ASP.NET MVC y justamente la otra vez me cruce con esta excelente entrada en DotNet Tricks que me motivo a escribir sobre un tema que siempre posponía: el pipeline de ASP.NET MVC y sus puntos de extensión.

En esta primer entrega vamos hablar sobre la etapa de routing del pipeline, con una breve descripción de la función que cumple y las diferentes formas en que podemos extenderlo. En próximas entregas vamos a ir hablando de las siguientes faces: “Controller Initialization”, “Action Execution”, “Result Execution” y “View Initialization & Rendering”.

Routing

Routing

Routing

Esta es la primer etapa del pipeline y su función se centra en determinar quien será el encargado de manejar la petición.

Como ya todos saben el framework ASP.NET MVC nos provee de un motor de enrutamiento – routing engine – que se encarga de parsear la URL del request entrante y luego de machearla/mapearla contra alguna de las rutas – routes – almacenadas en la tabla de enrutamiento – route table –. A partir de la ruta coincidente podremos determinar que handler será el encargo de manejar la petición – el comportamiento por defecto es determinar el controlador y acción que deben ser invocados – pero como veremos más adelante podemos extendernos en este punto.

Sigue leyendo

Pero que mareo con ASP.NET vNext

Hace tiempo que vengo trabajando con ASP.NET, en particular con su framework MVC, y si había algo con lo que estaba conforme era la forma en que se venía lanzando las versiones del mismo. La periodicidad con el que sacaban nuevas versiones permitía conocer “a fondo” el framework y estaba relativamente claro cuales eran las features introducidas como las dependencias con .NET. Estas y otras cosillas nos daban mayor confianza para dar el salto.

Todo bien hasta el anuncio de ASP.NET vNext. De entrada se habló de dos alternativas para trabajar en ASP.NET: la tradicional y una variante que correrá con .NET Core (este último para quien no lo conozca es una versión “ligth”, más rápida y multiplaforma del framework .NET).

Por lo tanto surgen “dos versiones” de nuestro querido framework web:

  • ASP.NET 4.6: sigue el curso “normal” del framework, es decir la misma forma de trabajo que ahora con la clásicas tecnologías ASP.NET MVC, Web API, WebForms, SignalR.
  • ASP.NET 5 o ASP.NET vNext: que esta pensado para trabajar sobre .NET Core y que deja afuera tecnologías como WebForms por ejemplo.

Conclusión, tenemos ASP.NET 4.6 que corre en la versión “completa” de .NET – .NET Full Framework 4.6 – y ASP.NET 5 que correrá en ambas versiones, la versión “full” y la “ligth” de .NET – .NET Core 5 -.

ASP.NET vNext

ASP.NET vNext

Y llegan los dolores de cabeza, porque si trabajamos con MVC en ASP.NET 4.6 estaremos trabajando con ASP.NET MVC 5.x y en cambio si lo hacemos sobre ASP.NET 5 sera ASP.NET MVC 6. Lo mismo pasa con otros frameworks como SignalR, en ASP.NET 4.6 es SignalR2 y en ASP.NET 5 tenemos SignalR3.

No perdamos de vista que ASP.NET 5 esta siendo escrito desde cero para la tecnología .NET Core, por lo que será incompatible con ASP.NET 4.6 y anteriores.

Para quienes no lo tengan presente .NET Full Framework 4.6 se presentó en el lanzamiento de Visual Studio 2015 mientras que la versión Release Candidate de .NET Core 5 estaría a finales de año. Es decir que, ya podemos trabajar con una de las alternativas pero debemos esperar – ¿mucho? – para trabajar con tranquilidad en la otra (y eso que llevan un largo tiempo anunciándolo).

Ahora bien, ¿qué se trae de nuevo ASP.NET MVC 6?. Rápidamente comentarles que tiene una nueva estructura de los proyectos, desaparece el archivo global.asax y aparece la clase Startup, desaparece nuestro viejo y querido web.comnfig y aparecen nuevos archivos de configuración JSON (global.json, bower.json, config.json, package.json y project.json), nuevos folders como “wwwroot”, integración con nuevos gestores de paquetes, desacoplamiento de IIS lo que nos permite tener nuestra aplicación auto hosteada en múltiples plataformas, etc. Pronto estaré escribiendo sobre el tema.

Resumiendo, creo anunciar vNext de forma tan temprana hizo que los desarrolladores nos confundamos más de la cuenta, más aún si tenemos en consideración toda esta tramoya de versiones. Esperemos que con el tiempo todo esto se normalice y haya más novedades al respecto. Mi opinión personal, arrancar con ASP.NET 4.6 y de paso ya ir “jugando” cada vez más con ASP.NET 5 hasta su lanzamiento.

Para mayor información sobre el tema recomiendo absolutamente el siguiente articulo: Descifrando el lío de ASP.NET vNext: versiones, disponibilidad, Visual Studio…

SignalR – Introducción

SignalRHace tiempo que tengo intenciones de comenzar a escribir sobre este tema, pero por una cosa u otra lo fui postergando. Para quienes no lo conozcan, SignalR es un framework de la pila de tecnologías web de Microsoft pensado para la construcción de aplicaciones en tiempo real. Las aplicaciones web con funcionalidad en tiempo real son aquellas que tienen la capacidad de enviar – desde el servidor – notificaciones al instante a los clientes conectados, en lugar de esperar que ellos vuelvan a solicitarlos ya sea por medio de polling o requests.

Ejemplos de este tipo de aplicaciones son los juegos “online” multi-usuarios, herramientas colaborativas como por ejemplo Google Docs u Office Web Apps, servicios de notificaciones en vivo, chats y otros tipos de servicios que actualmente son muy comunes de ver en aplicaciones como Facebook y Twiter.

La definición para SignalR que nos da el sitio oficial es la siguiente:

ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. What is “real-time web” functionality? It’s the ability to have your server-side code push content to the connected clients as it happens, in real-time.

SignalR es el marco de trabajo perfecto para el desarrollo de aplicaciones en Internet que soporten múltiples usuarios colaborando al mismo tiempo.  Y para que esto sea posible nos provee de una API que abstrae al desarrollador de las cuestiones de bajo nivel y nos brinda componentes para ambos extremos de la comunicación – cliente y servidor – tema que ya veremos más adelante.

Es importante saber que es una librería que se monta sobre el stack de tecnologías para la web ASP.NET y se encuentra al mismo nivel de otros frameworks bien conocidos por nosotros como Web API o MVC:

SignalR

SignalR

Como bien lo muestra el gráfico tanto SignalR como Web API están pensados para resolver implementaciones orientadas a servicios mientras que Web Forms y MVC fueron diseñados para la construcción de aplicaciones web.

Siguiendo la movida que implementó Microsoft en los últimos años, SignalR es open source – licencia Apache 2.0 – lo que nos permite estudiar sus fuentes y colaborar a través de GitHub. La versión 1.0 salio en Febrero de 2013 y la versión 2.0 unos meses más tarde en Octubre del mismo año. Al momento de escribir esto se encuentra en la versión 2.2.0 que se lanzo en Enero de este año y es la que utilizaremos en los próximos post.

Para finalizar con esta pequeña introducción contarles que SignalR está siendo utilizado en muchos proyectos reales como ser Web Apps de Office, SkyDrive y Office 365 entre otras, lo que habla de un marco de trabajo estable. Otro ejemplo es el juego Shootr construido en su totalidad con esta tecnología.

En las próximas entregas vamos a contar algunas de las características que hacen de este framework una opción perfecta para la creación de aplicaciones multi-usuarios en tiempo real de una manera realmente sencilla para los desarrolladores.

¡Nos vemos!

Nuevo blog! Microsoft Dev Blog

Es para mi un gusto compartir con toda la comunidad el blog Microsoft Dev Blog que comenzamos recientemente con mi gran compañero y amigo @diegobersano. Hace ya un tiempo que venimos con la idea de armar este blog en conjunto, pero por distintos motivos y falta de tiempo se venia postergando.

Microsoft Dev Blog tiene como fin poder compartir los conocimientos y experiencias  que vamos adquiriendo en tecnologías .NET, en principio arrancaremos con Azure pero tenemos pensado ir escribiendo sobre Windows Phone y ASP.NET entre otras novedades tecnológicas.

Microsoft Dev Blog

Microsoft Dev Blog

Espero que les sea útil y desde ya estamos a disposición de todos!

Razor Helpers

Para aquellos que venimos trabajando desde el inicio con ASP.NET MVC recordaran que con la versión de MVC 3 aparecía Razor, el view engine que nos permitía armar vistas mas simples escribiendo menos caracteres 🙂

Hoy vamos a hablar de una característica de Razor que muchas veces se nos pasa por alto, pero que les puede resultar muy útil. Se trata de la sintaxis @helper que nos permite escribir métodos auxiliares re-utilizables en las vistas.

Trabajemos en un simple ejemplo para apreciar la utilidad de esta sintaxis. Supongamos que tenemos una lista que muestra información sobre personas y en una de las columnas es necesario mostrar su dirección postal. Para el caso en que no existiera esta información hay que mostrar la frase “No se cuenta con la dirección postal“.

Como ya se imaginan, esto requiere escribir una simple porción de lógica en la vista que muestre el texto que corresponda dada una condición determinada. Para esto vamos a crear un método auxiliar con la sintaxis @helper que vamos a llamar MostrarDireccionPostal:

Definiendo un Razor Helper

Definiendo un Razor Helper

Sencillo, no?… Seguramente se estarán preguntando cómo podemos hacer para reutilizar esté método en otras vistas de mi aplicación sin necesidad de re-escribir el @helper en cada una de estas vistas. Para esto simplemente debemos mover nuestro método a un archivo con extensión .cshtml o .vbhtml dentro del directorio “/App_Code” (en mi caso lo voy a llamar SebysHelpers.cshtml):

SebysHelpers Template

SebysHelpers Template

Tengan en cuenta que el template SebysHelpers.cshtml se compila bajo la clase SebysHelpers la cual me va a proveer del método estático MostrarDireccionPostal (dentro del template podemos poner cuantos métodos queramos). Hecho esto finalmente resta modificar la vista para invocar el método correspondiente:

Invocando al método dentro del template.

Invocando al método del template.

Como podemos ver el uso de la sintaxis @helper nos permite encapsular lógica del renderizado de las vistas en métodos auxiliares que podemos compartir entre deferentes vistas de una manera muy sencilla y generando código mas legible y mantenible.

Espero que les sea de mucha utilidad.

Abrazos!

ASP.NET MVC 4 – Remote Validation

Como ya hemos visto en un post anterior con solo definir un conjunto estático de reglas en los atributos de nuestro modelo basta para definir las validaciones del lado del cliente (esto gracias a la librerías DataAnnotations – C# – y jquery Validation – JS -). Sin embargo, hay situaciones donde este conjunto estático de reglas no es suficiente, y es necesario aplicar lógica “de negocio” en la validación de un atributo (por ejemplo, un formulario de registración en el que se necesita validar si el e-mail ingresado no esta asociado a una cuenta ya existente). Los casos similares a este último son apropiados para implementar validaciones remotas.

ASP.NET MVC 4 nos provee un mecanismo muy simple para realizar validaciones remotas. Por un lado vamos a necesitar un método de acción en donde vamos a realizar la lógica de validación propiamente dicha. Podría ser algo como lo siguiente:

Método de Acción donde realizamos la validación.

Método de Acción donde realizamos la validación.

Como podemos ver, la acción devuelve un objeto JsonResult indicando si la validación fue exitosa (true value) y en caso contrario un mensaje explicativo (string value). Como segundo parámetro de la respuesta, le pasamos el valor de enumerado JsonRequestBehavior.AllowGet el cual nos permite enviar JSON en una respuesta de una petición GET.

Bien, ahora para asegurarnos que la validación remota se dispare, debemos agregar el atributo [Remote] en el modelo. Este atributo espera el nombre del controlador y la acción que deben ser llamadas. Cuando el usuario ingrese los datos en la caja de texto, el cliente sabe que debe invocar al método de acción indicado con el valor ingresado:

Agregando el atributo Remote a nuestro modelo.

Agregando el atributo Remote a nuestro modelo.

También es necesario habilitar las características ClientValidation y UnobtrusiveJavascript desde el web.config:

1:<appSettings>
2:  <add key= "ClientValidationEnabled " value= "true "/> 
3:  <add key= "UnobtrusiveJavaScriptEnabled " value= "true "/> 
4:</appSettings>

Por último corremos la aplicación y probamos nuestra validación remota:

Remote Validation in action!

Remote Validation in action!

Espero que les sea de utilidad!