En más de una ocasión me he topado con artículos que sugerían que ASP.NET Core MVC es un middleware y de hecho, incluso en algunos momentos yo también he tenido la sensación de que podía serlo.

Sin embargo, y esta es la respuesta corta si quieres ahorrar tiempo de lectura, estrictamente hablando no lo es.

La respuesta larga

Está claro que el framework MVC está presente de alguna u otra forma en el pipeline de ASP.NET Core, lo que hace pensar que sí podría existir una especie de "middleware MVC" capaz de engancharse al pipeline para poder participar en el proceso de peticiones.

La respuesta la encontramos fácilmente buceando en el código del framework. Si echamos un vistazo al fuente del extensor UseMvc() que utilizamos para insertar MVC en el pipeline encontramos lo siguiente (he limpiado un poco el código para que se entienda mejor):

/// <summary>
/// Adds MVC to the <see cref="IApplicationBuilder"/> request 
/// execution pipeline.
/// </summary>
public static IApplicationBuilder UseMvc(
    this IApplicationBuilder app,
    Action<IRouteBuilder> configureRoutes)
{
    [...]

    // Verify if AddMvc was done before calling UseMvc
    // We use the MvcMarkerService to make sure if all the services were added.
    if (app.ApplicationServices.GetService(typeof(MvcMarkerService)) == null)
    {
        throw new InvalidOperationException(
            Resources.FormatUnableToFindServices(
               nameof(IServiceCollection),
               "AddMvc",
               "ConfigureServices(...)")
        );
    }

    var routes = new RouteBuilder(app)
    {
        DefaultHandler = app.ApplicationServices
                            .GetRequiredService<MvcRouteHandler>(),
    };

    configureRoutes(routes);

    routes.Routes.Insert(0, 
        AttributeRouting.CreateAttributeMegaRoute(app.ApplicationServices)
    );

    return app.UseRouter(routes.Build());
}

Lo que se hace aquí es lo siguiente:

1. Primero, se verifica que los servicios de MVC fueron añadidos al sistema solicitando una instancia de MvcMarkerService. Si no existe, es que se ha llamado a AddMvc() en la configuración de servicios, por lo que se lanza una excepción.
    
2. Se crea un RouteBuilder al que se asocia por defecto el handler MvcRouteHandler. En otras palabras, se comienza a preparar un grupo de rutas cuyo proceso será delegado al framework MVC.
    
3. Se invoca el delegado suministrado por el desarrollador para que añada las rutas al builder que estamos definiendo. Este delegado es el que suele configurar las convenciones de rutas, como en el siguiente código:
   

   app.UseMvc(routes =>
   {
       // Delegado de configuración de rutas
       routes.MapRoute(
           name: "default",
           template: "{controller=Home}/{id?}");
   });

4. Se insertan en primera posición las rutas definidas por atributos, de forma que tengan prioridad sobre el resto. Por cierto, CreateAttributeMegaRoute(), vaya pedazo de nombre para un método, ¿verdad? ;D
    
5. Por último, se añade el middleware de routing de ASP.NET Core que hemos configurado.

Este punto es el que andábamos buscando y que da respuesta a la pregunta que nos hacíamos al principio. Por tanto, MVC no se añade al pipeline como un middleware, simplemente configura un RouterMiddleware de forma que las peticiones dirigidas a las rutas configuradas sean procesadas por MvcRouteHandler, que será el encargado de seleccionar la acción e invocarla.

Publicado en Variable not found.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

.NET

• When a disk cache performs better than an in-memory cache (befriending the .net GC)
  Dan Roberts
• Asynchronous Programming in C# using Async Await – Best Practices
  Damir Arh
• The week in .NET: On .NET with Steeltoe – C# Functional Extensions – Firewatch
  Bertrand Le Roy
• Inspecting aspects and interception in .NET, part I, II & III
  Erik Heemskerk
• Compact strings in the CLR
  Matt Warren
• Designing with Exceptions in .NET
  Jonathan Allen
• Channelling my inner geek
  Marc Gravell

Pues sí, como comentaba el amigo Gustavo en el post de despedida preveraniego, ya iba siendo hora de volver al frente de batalla. Y si he tardado no es porque haya estado desde entonces tumbado en una hamaca (¡más quisiera!), sino más bien por lo contrario. En breve os contaré más sobre el proyecto en el que ando metido, porque seguro que a muchos os va a interesar :)

Pero bueno, retomando las buenas costumbres, ahí lleváis los enlaces recopilados durante la semana pasada. Como siempre, espero que os resulten interesantes ;-)

.NET

• SOLID Design principles with C# practical examples
  Vikram Chaudhary
• Subverting .NET Type Safety with 'System.Runtime.CompilerServices.Unsafe'
  Matt Watten
• The week in .NET: .NET Core 1.0.1 – On .NET with Peachpie – Avalonia – Folk Tale
  Bertrand Le Roy
• Announcing September 2016 Updates for .NET Core 1.0
  Rich Lander
• Aspect Oriented Programming (AOP) in C# with SOLID
  Yacoub Massad
• Overusing the Null-Conditional Operator
  Colin Angus Mackay

Parecía que no llegaban, pero por fin están aquí las vacaciones :)

Como suele ser habitual por esta época, colgaré temporalmente los hábitos digitales y durante las próximas semanas el blog quedará a merced de las olas. Aunque la mayor parte del tiempo seguiré trabajando en distintos temas, espero poder reducir un poco la intensidad y tomar aunque sea algunos días de descanso para poder disfrutar de la familia y darme algún que otro bañito relajante en las costas de Cádiz.

Espero que nos veamos a la vuelta, todos morenitos y con las pilas al 100%, ya en el mes de septiembre.

¡Felices vacaciones, amigos!


Imagen: Atardecer en Costa Ballena (Rota-Cádiz)
Autor: Ramón Sobrino https://trapatroles.wordpress.com/2015/04/08/rota-cadiz/

Continuamos lamiéndonos las heridas provocadas por los sucesivos terremotos que han supuesto las prereleases y releases públicas de ASP.NET Core, con objeto de ponernos al día en los cambios y novedades que vamos encontrando.

Hoy vamos a hablar de las variables de sesión, un tema que ya tratamos por aquí hace bastante tiempo, pero que conforme evolucionaba el producto ha cambiado lo suficiente como para dedicarle un nuevo post.