Lecturas recomendadas sobre c# y .net · septiembre 2019


Lecturas recomendadas sobre c# y .net de septiembre


1. You are naming your tests wrong!

¿Utilizas test unitarios o tienes pensado iniciar un proyecto y hacer uso de ellos? Si es el caso, te recomiendo You are naming your tests wrong! (Vladimir Khorikov).

Una de las más destacadas, y probablemente una de las menos útiles, es la siguiente convención:

[MethodUnderTest]_[Scenario]_[ExpectedResult]

2. You're Using HttpClient Wrong

Si programas en .Net tarde o temprano vas a tener que conectarte a la API de un tercero. La clase que te va a facilitar esa conexión es HttpClientPues bien, instanciar esta clase correctamente es todo un reto. Si googleas un poco verás docenas de artículos sobre cómo usarla. Por suerte aquí puedes encontrar la solución definitiva: You're Using HttpClient Wrong (Peter Vogel).

ASP.NET Core tiene una opción mejor: HttpClientFactory. HttpClientFactory proporciona objetos HttpClient pero asume la responsabilidad de administrar los recursos que los clientes pueden usar. Piensa en ello como "conexiones pooling para servicios web".

3. Getting Started With Blazor

¿Te suena Blazor? Es el nuevo framework de Microsoft para ejecutar c# en el navegador. Imagínate, en lugar de escribir javascript para virguerías en la página lo escribes en c#. ¿Podré reaprovechar los modelos del servidor/backend en el navegador/frontend? Sí. Yo no lo he utilizado todavía pero me gustaría. Aquí va una guía sobre cómo empezar: Getting Started With Blazor (Michael Washington).

En este artículo crearemos un proyecto Blazor predeterminado y exploraremos los componentes y características.

4. Linq Style Mapping for Single Objects

Aquí encontrarás una pequeña función que podrás incoporar a tu proyecto para realizar lo mismo que la función Select() pero para objetos individuales: Linq Style Mapping for Single Objects (Steve Fenton).

Linq no es solo la biblioteca de .NET para el manejo de fuentes de datos IEnumerable, es la inspiración para muchos intentos exitosos y no exitosos de reproducir el estilo en otros idiomas.

5. Modifying Data with Entity Famework Core

Rendimiento vs EntityFramework, un tema bastante posteado. Parece ser que utilizar EntityFramework no es lo más rápido del mundo, pero en mi caso nunca he tenido problemas de rendimiento, al revés, me ha salvado el cuello. En todo caso, en el post Modifying Data with Entity Famework Core de Marinko Spasojevic encontrarás una guía con todas las maneras de hacer UPDATE, algunas de las cuales consisten en lanzar UPDATES directos sin recuperar antes los registros.

Vamos a aprender cómo modificar el contenido de la base de datos (Crear, Actualizar, Eliminar).

6. Use Performance Counters in .NET to measure Memory, CPU, and Everything – Full Guide

Resulta que Windows lleva incorporada una herramienta "Performance Monitor" que puede medir métricas de rendimiento de las aplicaciones. Aquí te dejo una guía completa de cómo usar esta y otras herramientas para medir el rendimiento de tu aplicación: Use Performance Counters in .NET to measure Memory, CPU, and Everything – Full Guide (Michael Shpilt). 
Me pregunto en cuántos proyectos se llegan a utilizar este tipo de herramientas. Que yo conozca, cero cósmico. Siempre que leo estos artículos me pregunto si soy un amateur del software y un irresponsable al no usarlas, pero claro, a mis clientes les importan un bledo estas métricas, con tal de que la aplicación funcione y no vaya a pedales, - "lo más económico posible por favor".

Hay un increíble mecanismo incorporado en Windows llamado Performance Counters que te permite monitorizar una gran cantidad de métricas útiles. Es fácil de usar, es gratis y quizás no se use tanto como se merece.

7. Full Modular Monolith application with Domain-Driven Design approach

Domain Driven Design. La siguente lecura que comparto es un repositorio de Git sobre una aplicación monolítica y modular que aplica Domain Driven Design y que según su autor podría utilizarse en producción: Full Modular Monolith application with Domain-Driven Design approach (Kamil Grzybek). Aviso, es Domain Driven Design en vena. Mucho concepto y muy seguido.

  • Mostrar cómo se puede implementar la aplicación monolítica de forma modular
  • (...) la implementación de la aplicación que estaría lista para ejecutarse en producción
  • Mostrar las mejores prácticas y principios de programación orientados a objetos.
  • Presentar el uso de patrones de diseño. Cuándo, cómo y por qué se pueden usar.
  • Presentar algunas consideraciones arquitectónicas, decisiones, enfoques.
  • Utilizando el enfoque de diseño dirigido por dominio.
  • Presentar pruebas unitarias para el modelo de dominio (diseño comprobable en mente).

8 .Declarative framework for building command line interfaces

Has desarrollado una aplicación de gestión y tanto los usuarios como el cliente están satisfechos. Tarde o temprano te van a pedir una funcionalidad que se va ha ejecutar en background cada cierto tiempo, o por las noches, o cada minuto. ¿Qué opciones tienes?

a) Un job de base de datos (peligro, danger, cuidado, atención) 

b) Un servicio de Windows (bueno... puede salir bien, pero voy a lidiar con más temas de los que me gustaría)

c) Aplicación de línea de comandos que puedes ejecutar desde el programador de tareas de Windows (opción que analizo en primer lugar)

Si escoges la opción c) verás que desarrollas la primera tarea en background sin complicarte demasiado la vida. Lo más probable es que funcione y por ello te van a seguir pidiendo nuevas tareas que también se ejecutarán en background. Y entonces tendrás que pensar una manera de parsear los inputs de tu aplicación de línea de comandos. Querrás ejecutar diferentes funciones que además tengan diferentes parámetros. Puedes leerte el siguiente artículo y ahorrarte horas y horas de trabajo: Declarative framework for building command line interfaces (Alexey Golub)

CliFx es un marco fácil de usar pero potente para crear aplicaciones de línea de comandos. Su objetivo principal es hacerse cargo por completo de la capa de entrada del usuario, lo que le permite centrarte más en escribir tu aplicación. Este marco utiliza un enfoque declarativo para definir comandos, evitando código repetitivo excesivo y configuraciones complejas.

9. AutoWrapper: Prettify Your ASP.NET Core APIs with Meaningful Responses

¿Qué tipo de mensajes debe devolver una API? Si se produce un error ¿qué es preferible devolver? Aquí te dejo un artículo que puede ayudarte a tomar este tipo de decisiones: AutoWrapper: Prettify Your ASP.NET Core APIs with Meaningful Responses (Vincent Maverick Durano).

Como desarrollador de API que comprende a los consumidores, queremos dar respuestas API significativas y consistentes.

10. A few Implementations of Message Bus/Broker

Este artículo describe diferentes maneras de implementar un Event Aggregator (o Message Bus/Broker). Yo utilizo uno de estos en una aplicación Windows que tiene pestañas y en la que por ejemplo al hacer un cambio en una de las pantallas espero que la otra se actualice automáticamente sin que el usuario deba refrescar la pantalla. A few Implementations of Message Bus/Broker (Lộc Nguyễn)

Cuando un proyecto comienza a crecer, una de las necesidades que siempre se vuelve más y más importante es encontrar una forma de comunicación entre los componentes. Para ello se utiliza un Event Aggregator (o Message Bus/Broker).




Quizá algun día empiece a enviar una newsletter, si te gustaría recibirla subscríbete aquí

Archivo