miércoles, 4 de mayo de 2016
Nota: existe una actualización de este post a la RC2 de ASP.NET Core. Mejor que leas esa ;)
Uno de los requisitos más habituales que tenemos en cualquier aplicación medianamente compleja es la creación de logs donde guardar información cuando ocurran determinados eventos.En ASP.NET "clásico" teníamos varias opciones, como utilizar las propias herramientas de tracing del framework o frameworks especializados de terceros como los célebres Log4Net, NLog o muchos otros, pero al final la idea era la misma, poder disponer de un componente en el que poder registrar sucesos como el siguiente:
public ActionResult RemoveInvoice(string id)
{
... // Remove the invoice
_logger.LogInformation($"Invoice {id} was removed by {User.Identity?.Name}");
return RedirectToAction("Index");
}
El nuevo ASP.NET Core viene equipado de serie con un sistema de logging interno, integrado en el propio marco de trabajo, que proporciona funcionalidades básicas pero, sobre todo, los mimbres básicos sobre los que montar sistemas de trazas más complejos y personalizables. Dedicaremos este post a ver cómo se configura y utiliza este mecanismo que, como otros aspectos del framework, está construido pensando en su extensibilidad, y hace uso intensivo del sistema de inyección de dependencias.
Nota: aunque este componente no es un gran candidato a cambiar dada las pocas actualizaciones que ha sufrido en los últimos meses, es bueno recordar que todavía estamos utilizando una release candidate de ASP.NET Core y, por tanto, algunos detalles aún podrían variar antes de que aparezca la versión final del producto.
martes, 3 de mayo de 2016
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-).Net
- Building strongly typed application configuration utility with Roslyn
Filip Woj - Background Tasks in .NET
Derek Comartin - The week in .NET – 4/27/2016
Bertrand Le Roy - Choosing The Right Collection
Arthur Minduca - The .NET of Tomorrow
Ed Charbeneau - Serializing JSON Data into Binary Form
Mahesh Sabnis - Thread.Sleep in Tests Is Evil
Steve Smith - netstandard–El “estándar” que viene
Eduard Tomás
martes, 26 de abril de 2016
Al hilo de lo tratado en el último post sobre la ramificación del pipeline de ASP.NET Core utilizando los extensores
Map() y MapWhen(), el amigo Fernando V. dejaba una pregunta interesante en los comentarios del blog:"[…] Igual que hemos visto cómo ramificar el pipeline, sería posible volver a unir las distintas ramas en una sola?"Tampoco creo que sea muy habitual crear este tipo de estructuras en el pipeline, pero la verdad es que me ha parecido un reto muy interesante, lo suficiente como para dedicarle un post ;D
lunes, 25 de abril de 2016
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-).Net
- Exploiting the ConcurrentDictionary in Asynchronous Applications
Peter Vogel - Edit and Continue Part 2 – Roslyn
Josh Varty - Why Azure REST API-s and how to prepare for using them?
Gunnar Peipman - The week in .NET – 4/19/2016
Bertrand Le Roy - Edit and Continue Part 1 – Introduction
Josh Varty - Introducing the Microsoft .NET Framework Repair Tool Version 1.3
Rakesh Ranjan Singh - If You Want to Get Into OSS, Consider This Project
James Chambers - 2D Polyline Vertex Smoothing
Ven RP
martes, 19 de abril de 2016
Al representar gráficamente el pipeline de ASP.NET Core, lo habitual es hacerlo como una tubería única en las que colocamos estratégicamente los middlewares que procesarán las peticiones que entrarán por ella.
Incluso a nivel de código, la inserción de middlewares se realiza normalmente invocando métodos del tipo
UseXXX() sobre la instancia de IApplicationBuilder que recibimos en el método Configure() de la clase Startup de nuestras aplicaciones ASP.NET Core.Esto parece dar a entender que el pipeline es lineal, y que todas las peticiones serán procesadas de la misma forma y por los mismos middlewares, salvo que alguno de ellos decida cortocircuitar la petición.
Sin embargo, aunque eso será lo más frecuente, no es obligatoriamente así. Ya desde los tiempos de Katana tenemos la posibilidad de dividir el pipeline en branches o ramas en función de determinados criterios, permitiéndonos crear configuraciones mucho más complejas y potentes que las que habitualmente suelen mostrarse.Como ejemplo, en el diagrama lateral podemos observar un pipeline en cuya entrada se encuentra un middleware de gestión de errores, y que a continuación se divide en función de la ruta de la petición de entrada. Así, las peticiones cuyas rutas comiencen por "/SignalR" serán procesadas por los middlewares configurados en la rama de la izquierda; las que comiencen por "/API" serán procesadas a lo largo de la rama derecha, y el resto continuará su proceso por la rama central.
Vamos a ver cómo conseguir crear estas estructuras, pero, como siempre, tened en cuenta que estamos aún trabajando con una versión preliminar de ASP.NET Core y hay detalles que podrían cambiar en la versión definitiva.
