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

Por si te lo perdiste...

• Extendiendo claims de usuarios en ASP.NET Core
  José María Aguilar
• Problemas al comentar el código fuente
  José María Aguilar

.NET / .NET Core

• .NET Core January 2019 Updates – 2.1.7 and 2.2.1
  Lee Coward
• Codez: A Random String Generator and Why I Wrote It
  Khalid Abuhakmeh
• Rendering Markdown to HTML and Parsing YAML Front Matter in C#
  Mark Heath
• Do we need JVM’s PhantomReference in .NET?
  Konrad Kokosa
• Implementing Phantom Reference in C#
  Oren Eini
• Implementing Java ReferenceQueue and PhantomReference in C#
  Kévin Gosse
• Collectible assemblies in .NET Core 3.0 | StrathWeb. A free flowing web tech monologue.
  Filip Woj
• Announcing ML.NET 0.9 – Machine Learning for .NET
  César de la Torre
• Profiling Concurrent .NET Code with BenchmarkDotNet and visualizing it with Concurrency Visualizer
  Adam Sitnik
• Deep-dive into .NET Core primitives, part 3: runtimeconfig.json in depth
  Nate McMaster

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

Por si te lo perdiste...

• Renderizar una vista Razor a un string en ASP.NET Core MVC
  José María Aguilar
• Top posts 2017 en Variable not found
  José María Aguilar

.NET / .NET Core

• Generate automatically async/await code from sync code with Roslyn
  Alexandre Mutel
• Background jobs in ASP.NET Core made easy with Hangfire
  Matthew D. Groves
• How to parse a high rate stream of data with low memory allocation
  Riccardo Terrell
• Comparing RestSharp and Flurl.Http while consuming a web service in .NET Core
  Jeremy Lindsay
• Less commonly used C# operators
  Damir Arh
• SOLID Principles in C# - Open Closed Principle
  Marinko Spasojevic
• Build your first .NET Core 3.0 application in Linux
  Anuraj Parameswaran
• Implement Observer Pattern in .NET (3 Techniques)
  Chinmoy Mohanty
• String Interpolation Functions vs. string.Format Constants
  Scott Hannen
• Using Polly and Flurl to improve your website
  Jeremy Lindsay
• Image Classification Using Keras
  James McCaffrey
• Accessibility of nested classes
  Eric Lippert
• Find, Fix, and Avoid Memory Leaks in C# .NET: 8 Best Practices
  Michael Shpilt

Desde hace una década, el primer post de enero siempre lo reservo para revisar qué publicaciones del blog han sido las más visitadas del año recién finalizado, así que vamos a continuar con esta arraigada tradición una vez más ;)

También, como no podía ser de otra forma, aprovecho también para desearos a todos un año 2019 lleno de alegrías tanto en el terreno personal como en el profesional, deseo que podéis considerar extensible para a todos los que os rodean y os importan :)

Y dicho esto, vamos al tema...

Desde que apareció Roslyn, C# ha ido evolucionando a pasos agigantados. Tanto es así que es frecuente encontrar desarrolladores que, aunque lo usan a diario, desconocen todo su potencial porque la velocidad de introducción de cambios en el lenguaje es mayor que la de asimilación de novedades por parte de los profesionales que nos dedicamos a esto.

Por ejemplo, en las consultorías técnicas que realizo en empresas es frecuente encontrar equipos de trabajo en los que aún no está generalizado el uso de construcciones tan útiles como el null coalescing operator (fullName ?? "Anonymous"), safe navigation operator (person?.Address?.Street), el at object operator (Address@person), o características tan potentes como las funciones locales, interpolación de cadenas, tuplas o muchas otras.

Sin embargo, creo que el rey de los desconocidos es el operador virgulilla "~" de C#. Introducido con C#7 es probablemente uno de los operadores menos utilizados y, sin embargo, de los más potentes ofrecidos por el lenguaje.

Nota de traducción: el nombre original del operador es "tilde operator", y como he encontrado poca literatura al respecto en nuestro idioma, me he tomado la libertad de traducirlo como operador virgulilla (¡sí, esa palabra existe!). También, en entornos más informales lo encontraréis con el nombre "wormy operator" (operador gusanillo) o como "soft similarity operator" (que podríamos traducir como operador de similitud relajada).

Ahí van los enlaces recopilados durante la semana pasada y, como siempre, espero que os resulten interesantes :-)

Y de paso, aprovecho este momento  para desearos a todos unas felices fiestas y un grandioso 2019 en todos los ámbitos.

Por si te lo perdiste...

• Xmas Tree scan, el escaneo de puertos navideño
  José María Aguilar
• Constantes string multilínea en C#
  José María Aguilar

.NET / .NET Core

• .NET Core - What's Coming in .NET Core 3.0
  Scott Hunter
• Composing Honest Methods in C#
  Yacoub Massad
• Comparaciones en C#
  Eduard Tomás
• ClosedXML, una manera fácil de dar formato a nuestros .xlsx
  Jorge Turrado
• VB.NET Hits High in Programming Language Popularity Index
  David Ramel
• Enable repeatable package restores using a lock file
  Anand Gaurav
• Garbage Collection in C# (.NET Framework and .NET Core)
  Damir Arh
• Writing a Roslyn analyzer
  Gérald Barré
• The Lazy applicative functor
  Mark Seemann
• Interesting uses of tuple deconstruction
  Nigel Sampson
• C# All The Things
  David Pine
• Presenting HttpTracer Library
  Daniel Causer
• How to Remove Application Insights
  Matt Watson
• C# Features: An Exhaustive List of the Best Ones
  Carlos Schults
• Updating Westwind.AspnetCore.Markdown with Markdown from Files and URLs
  Rick Strahl
• Top .NET Tutorials in 2018
  David Ramel

Hace unos días publicaba un post sobre la mala idea que era tener controladores con demasiadas responsabilidades y cómo un constructor con demasiadas dependencias podía ser una señal (un 'code smell') de que las cosas no estaban yendo bien en ese sentido.

Por ejemplo, echando un vistazo al siguiente controlador podemos ver claramente una violación del Principio de Responsabilidad Única (SRP) en un controlador que conoce demasiados detalles sobre la forma de proceder al registrar un pedido:

public class OrderController: Controller
{
    private readonly IOrderServices _orderServices;
    [...] // Other private members

    public OrderController(IOrderServices orderServices, IUserServices userServices, 
        IMailingService mailingServices, ISmsServices smsServices, 
        IPdfGenerator pdfGenerator, IMapper mapper
    )
    {
        _orderServices = orderServices;       
        _userServices = userServices;
        [...] // Other assignments...
    }

    [HttpPost]
    public Task<IActionResult> Submit(OrderViewModel orderViewModel)
    {
        if(!ModelState.IsValid)
        {
            return View(orderViewModel);
        }
        var orderDto = _mapper.Map<OrderDto>(orderViewModel);
        var orderResult = await _orderServices.AddAsync(orderDto);
        if(!orderResult.Success)
        {
            return RedirecToAction("OrderError", new { error = orderResult.Error }));
        }
        var userPreferences = await _userServices.GetNotificationPreferencesAsync(CurrentUserId);
        var pdfUrl = await _pdfGenerator.GenerateOrderAsync(orderResult.Details);
        if(userPreferences.NotificationMode == NotificationMode.Sms)
        {
            await _smsServices.NotifyNewOrderAsync(orderResult.Details, pdfUrl);
        } 
        else 
        {
            await _mailingServices.NotifyNewOrderAsync(orderResult.Details);
        }
        return RedirectToAction("ThankYou", new { id = orderResult.Details.OrderId } );
    }
    ...
}

En dicho post comentaba también algunas cosas que podíamos hacer para solucionar el problema, así como una recomendación de lo que no debíamos hacer: disimular dependencias instanciando directamente componentes o utilizando otros "sabores" de inyección que hicieran menos evidente la relación de nuestra clase con otras de las que depende.

Pues bien, como hoy estamos algo rebeldes, vamos a ver las técnicas que nos permitirían hacerlo cuando sea necesario o, dicho de otra forma, qué alternativas tenemos para usar dependencias desde los controladores sin que estas sean suministradas mediante inyección en su constructor.

Precaución: estas técnicas son consideradas antipatrones o, como mínimo, code smells en la mayoría de los escenarios, así que usadlas poco, con precaución y siempre con conocimiento de causa ;)