C#–Buenas prácticas en constructores

Escribir el constructor de una clase es algo que parece trivial… A fin de cuentas, el constructor se encarga de construir un objeto, ¿no? Pero la realidad es que escribir constructores no es tan sencillo como parece. ¿Qué significa “construir” un objeto? Por supuesto cada clase tendrá sus propias necesidades, pero hay una serie de guías y buenas prácticas que nos pueden ayudar a tomar ciertas decisiones. A esto va dedicado este post.

Continúa leyendo C#–Buenas prácticas en constructores

WebApi 2–Leer datos desde los headers

En un curso que he impartido sobre WebApi 2 me han comentado un escenario en el que mandaban un conjunto de datos en varias cabeceras HTTP propias y querían leer esos datos desde los controladores.

La verdad es que hay varias maneras de hacer eso en WebApi 2 y vamos a analizar algunas de ellas en este post. Eso nos servirá como excusa para recorrer algunos de los mecanismos de extensibilidad del framework.

Continúa leyendo WebApi 2–Leer datos desde los headers

Atributos con comportamiento: un mal diseño

Tarde o temprano, todo desarrollador ya se de ASP.NET MVC o WebApi necesita hacer sus propios filtros para validaciones propias de peticiones, logging, comprobación de precondiciones… En fin, lo habitual para lo que se usan los filtros, vamos.

Y tarde o temprano este desarrollador se da cuenta de que su filtro debería acceder a un determinado servicio de su aplicación: quizá necesita hacer una consulta a la bbdd, o a un determinado elemento de negocio, o acceder al sistema de logging o cualquier cosa más. Y este desarrollador, que conoce (y usa) la inyección de dependencias se encuentra con que no es posible inyectar dependencias en un filtro. Algunos desarrolladores buscaran cualquier otra alternativa, algunas mejores que otras, pero ninguna satisfactoria: crear un singleton, una clase estática o instanciar directamente el objeto en lugar de obtenerlo como una dependencia (y rompiendo cualquier abstracción realizada). Otros desarrolladores continuarán en su búsqueda. En esta fase de terquedad que nos caracteriza, pensaran “no, no es posible. Tiene que ver alguna manera”.

netstandard–El “estándar” que viene

Cuando .NET salió, las cosas eran muy sencillas: había una sola versión de .NET, el .NET Framework, así que como mucho debíamos saber para que versión de .NET era una determinada librería. “Oh, la librería es solo para .NET 2.0 y yo uso .NET 1.1, que mala suerte”. Al margen de eso no había mucho más, todos teníamos claro que significaba .NET.

Continúa leyendo netstandard–El “estándar” que viene

Creando formateadores de salida en asp.net core

Cuando salió WebApi lo hizo con la negociación de contenido incorporada de serie en el framework. Eso venía a significar, básicamente, que el framework intentaba suministrar los datos en el formato en que el cliente los había pedido. La negociación de contenido se basa (generalmente) en el uso de la cabecera accept de HTTP: el cliente manda en esa cabecera cual, o cuales, son sus formatos de respuesta preferidos. WebApi soporta de serie devolver datos en JSON y XML y el sistema es extensible para crear nuestros propios formatos.

“MVC clásico” (es decir hasta MVC5) no incluye soporte de negociación de contenido: en MVC si queremos devolver datos en formato JSON, debemos devolver explícitamente un JsonResult y si los queremos devolver en XML debemos hacerlo también explícitamente.

En ASP.NET Core tenemos a MVC6 que unifica a WebApi y MVC clásico en un solo framework. ¿Como queda el soporte para negociación de contenido en MVC6? Pues bien, existe soporte para ella, pero dependiendo de que IActionResult devolvamos en nuestros controladores. Así, si en WebApi la negociación de contenido se usaba siempre y en MVC clásico nunca, en MVC6 la negociación de contenido aplica solo si la acción del controlador devuelve un ObjectResult (o derivado). Esto nos permite como desarrolladores decidir sobre qué acciones de qué controladores queremos aplicar la negociación de contenido. Es evidente que aplicarla siempre no tiene sentido: si devolvemos una vista Razor su resultado debe ser sí o sí un HTML que se envía al cliente. No tendría sentido aplicar negociación de contenido sobre una acción que devolviese una vista. De hecho la negociación de contenido tiene sentido en APIs que devuelvan datos (no vistas) y en MVC6 para devolver datos tenemos a ObjectResult, así que es lógico que sea sobre este resultado donde se aplique la negociación de contenido.

En WebApi la negociación de contenido estaba gestionada por los formateadores (formatters). Básicamente a cada content-type se le asociaba un formateador. Si el cliente pedía datos en un determinado content-type se miraba que formateador podía devolver datos en dicho formato. Si no existía se usaba por defecto el formateador de JSON. En MVC6 se ha mantenido básicamente dicho esquema.

Continúa leyendo Creando formateadores de salida en asp.net core

Middlewares de autenticación en asp.net core

La autenticación y autorización de peticiones es una de las funcionalidades que más quebraderos da en el desarrollo de aplicaciones en ASP.NET. Además es que ha ido cambiando con el tiempo… En un escenario de internet, en ASP.NET clásico, ya fuese Webforms o MVC usábamos FormsAuthentication. Por otra parte cuando apareció WebApi, incorporó sus propios mecanismos de autenticación y autorización, generalmente basados en la implementación de MessageHandlers.

Continúa leyendo Middlewares de autenticación en asp.net core

Autenticación por AAD en ASP.NET Core

Este es un post introductorio, de una serie de posts, donde veremos como podemos integrar ASP.NET Core y Azure Active Directory (AAD). En este primer escenario el objetivo es tener una aplicación web, donde se requiera hacer login contra AAD para autenticarse.

Nota: El post está basado en la RC1 de ASP.NET Core… Lo digo porque bueno, a saber que romperán mejorarán en futuras versiones, pues igual algo cambia :)

Continúa leyendo Autenticación por AAD en ASP.NET Core

WebApi–¿objeto o HttpResonseMessage?

El otro día hablando con Carlos (aka @3lcarry) surgió el tema de como devolver datos en una WebApi. En WebApi tenemos hasta tres maneras generales de devolver unos datos desde una acción de un controlador. Devolver un objeto, devolver un HttpResponseMessage o devolver un IHttpActionResult. (Una discusión equivalente aparece en MVC6 donde tenemos dos alternativas, devolver un objeto o bien un IActionResult.) ¿Cuál es la mejor?

Continúa leyendo WebApi–¿objeto o HttpResonseMessage?

Creating middlewares de asp.net core

Asp.net core se basa en el concepto de middleware. En este modelo la petición web viaja a través de un conjunto de componentes. Cada componente recibe la petición y puede:

  1. Modificar la petición y enviarla al siguiente componente
  2. O bien, generar una respuesta y enviarla de vuelta al componente anterior.

Continúa leyendo Creating middlewares de asp.net core

Routers en asp.net core

Cuando hablamos del routing solemos referirnos al proceso por el cual una petición es enrutada hacia una acción concreta de un controlador. Esa definición es cierta en el contexto de una aplicación ASP.NET MVC (y/o WebApi) pero en ASP.NET Core, el concepto de routing es una parte integral del framework.

Por ello, en ASP.NET Core entendemos el routing como el proceso mediante el cual una petición web es enrutada hacia donde tenga que ser tratada. El destino puede ser una acción de un controlador, pero no tiene por qué (el middleware de MVC6 podría no estar instalado en el pipeline de la aplicación). En este post vamos a ver como funciona este proceso de enrutado.

Continúa leyendo Routers en asp.net core