Forem: Eduardo Barrios

Ingeniería de Software - Test Unitarios. Cómo tratar dependencias de BD con Base de Datos en memoria y Entity Framework Core

Eduardo Barrios — Tue, 24 Aug 2021 02:17:40 +0000

Comúnmente en ingeniería de software es necesario escribir código que comprueba la correcta funcionalidad de ciertos componentes de nuestros sistemas, obviamente estos deben poseer una arquitectura limpia o cualquier arquitectura de software definida bajo buenas prácticas y patrones de diseño que a su vez nos permitan probar de manera aislada cada parte de nuestro código.
Las dependencias son un tema inevitable dentro del software, estás pueden ser llamadas a una base de datos, peticiones mediante un cliente Soap o Rest, llamadas a cualquier servicio externo o recurso de Azure, etc. Pero en la etapa que concierne a las pruebas unitarias no necesitamos utilizar las dependencias reales para probar la funcionalidad y asegurar la calidad de nuestro código, es decir no necesito conectarme a la base de datos real de producción, pre-producción, qa, o desarrollo para probar que en verdad mi código inserta en la base de datos, o no necesito realmente conectarme a Azure a un servicio real como el de Azure Cosmos DB para probar las funcionalidades que existen dentro de mi código que utilizan ese servicio de Azure.
Para resolver este problema en esta fase del desarrollo de software recurrimos a utilizar Mocks, concepto que hace referencia a utilizar implementaciones fake que permiten simular cada uno de los diferentes casos o variaciones de comportamiento que podría ocurrir como resultado en nuestro código.
En este post abordaremos pruebas unitarias con el proveedor de base de datos en memoria de Entity Framework Core para tratar con una de las dependencias existentes en un proyecto que desarrolle hace algunos meses en .NET 5 (WebApi y Blazor WASM), consiste en un proyecto API con su respectiva aplicación SPA que expone información de paises y sus códigos, además está definido bajo una arquitectura limpia y buenas prácticas de código limpio y patrones de diseño.

Inicialmente necesitaremos tener un proyecto de Pruebas dentro de nuestra solución, personalmente me gusta utilizar un proyecto de pruebas de xUnit.

Después de crear nuestro proyecto de pruebas necesitaremos instalar el paquete Nuget Microsoft.EntityFrameworkCore.InMemory
utilizando la consola de administración de paquetes de Visual Studio.

Install-Package Microsoft.EntityFrameworkCore.InMemory -Version 5.0.9

Dentro de la estructura del proyecto existe una capa llamada Infrastructure la cuál contiene el contexto de datos real de Entity Framework Core que se conecta a la base de datos, también contiene las migraciones a la base de datos, una definición de Repositorio Genérico y del patrón Unit Of Work para gestionar las operaciones de una manera centralizada hacía la base de datos. Dentro del directorio Repositories existe una implementación custom para cada objeto representado con base en una tabla de base de datos, lo que queremos en este post es poder probar la funcionalidad de los repositories de manera aislada en nuestro proyecto de pruebas, todo esto sin tener que conectarnos a la base de datos real.

OK!

Vamos al código.

Necesitaremos crear un contexto de Entity Framework Core el cuál utilizaremos para pasarlo como parámetro a nuestra implementación fake de UnitOfWork, para esto crearemos un directorio llamado ResourcesDatabase en la raíz del proyecto de pruebas y seguidamente crearemos una clase llamada BaseContextTest.cs. Añadiremos el siguiente código.

Nota: en la clase BaseContextTest es necesario configurar el tipo de base de datos, en este caso en memoria, para luego pasar esa configuración a una instancia de nuestro contexto real que es el que necesitamos burlar para poder probar la funcionalidad del repository.
También crearemos una clase para inicializar nuestra base de datos en memoria.
Luego de preparar una implementación fake para probar la funcionalidad del repository procedemos a crear una clase llamada CountriesRepositoryTest.cs dentro de la ruta Infrastructure.Repositories.Tests/Countries y dentro de está clase podremos crear pruebas unitarias que hagan referencia a los diferentes casos de comportamiento que puedan ocurrir en el código del repository. Probaremos el caso en el que nuestro repository devuelve una lista de elementos de una tabla de la base de datos, para esto crearemos un método que haga referencia a esa prueba.

En este test cumplimos con uno de los fundamentos de los test unitarios, el patrón de las 3 A´s el cuál se organiza de la siguiente manera:
- Arrange (Organizar/Inicializar) => Inicializa los objetos y establece los valores de los datos que vamos a utilizar en el Test que lo contiene, en nuestro test creamos e inicializamos un objeto que implemente la interface IUnitOfWork haciendo uso de la librería Moq, en la siguiente línea pasamos el contexto propio del proyecto de pruebas unitarias a nuestro objeto fake de UnitOfWork ya que este será necesario para mandárselo al método constructor de la instancia de CountriesRepository, está es la clase a la cuál queremos probar su funcionalidad.
- Act (Actuar) => realiza la llamada al método a probar con los parámetros preparados para tal fin, en nuestro test creamos una instancia de CountriesRepository (clase que queremos probar) pasamos el objeto fake creado en el Arrange y luego invocamos al método del repository que queremos probar.
- Assert (Confirmar/Comprobar) => comprueba que el método de pruebas ejecutado se comporta tal y como teníamos previsto que lo hiciera, en nuestro test a manera de ejemplo y aprendizaje hacemos varias aserciones aunque no es lo recomendado.

Consejo de Expertos: Al escribir test unitarios, incluye solo una aserción por prueba, ya que si agregas varias aserciones en un caso de prueba, no se garantiza que se ejecuten todas. En la mayoría de los marcos de trabajo de pruebas unitarias, cuando se produce un error en una aserción de un test unitario, las aserciones siguientes se consideran fallidas automáticamente. Esto puede ser confuso, ya que la funcionalidad en componentes que realmente son correctas, se muestran fallidas.

Procedemos a ejecutar nuestro unit test recién creado y podremos comprobar que el test pasa correctamente.

Conclusiones:

Utilizar una librería de Mocks es bastante útil en el testing de código, ya que nos evita estar creando clases para abarcar cada uno de los comportamientos o resultados que pueda tomar nuestro código y que necesitamos probar.
En este post vimos una de las utilidades de las bases de datos en memoria aplicada al testing de código y la facilidad con la que podemos mockear un contexto de base de datos sin necesidad de conectarnos a la base de datos real para probar la funcionalidad del acceso a datos y demás operaciones involucradas.
La técnica de mock de dependencias en test unitarios es una técnica profesional, avanzada y muy utilizada que existe en la ingeniería de software para escribir test unitarios cortos y precisos y poder probar componentes que están correctamente desacoplados.

Link al respositorio en GitHub
https://github.com/EbarriosCode/BackendDotnet_CleanArchitecture/tree/master

Referencias

Píldoras de C#: Task Parallel Library (TPL) Procesamiento Multihilo y asíncrono

Eduardo Barrios — Sun, 20 Dec 2020 16:51:04 +0000

Esta publicación, forma parte del 3er. Calendario Adviento C# 2020, una iniciativa liderada por Benjamín Camacho.

A continuación les traigo mi aporte sencillo pero no menos importante en el desarrollo de software y el uso de características geniales del lenguaje de programación C# en este caso el procesamiento multithreading y asíncrono mediante TPL.

Para comprender TPL es necesario comprender algunos fundamentos respecto a como funcionan los hilos, el grupo de hilos, características del sistema operativo como el scheduler, procesos, registros, etc.

Es lógico pensar que a medida que las aplicaciones se vuelven indispensables en cualquier entorno también se vuelven más complejas y las expectativas del usuario aumentan, ante esta problemática los desarrolladores de software podemos tomar ventaja de sistemas multinúcleo y capacidades de respuesta optimas para crear aplicaciones que utilicen múltiples threads (hilos) y lograr el famoso paralelismo. Antiguamente las computadoras arquitectónicamente hablando fueron creadas siguiendo el diseño lógico denominado Arquitectura de Von Newmann, la cual contaba con una unidad de procesamiento, una unidad de control, entrada y salida, y la unidad de procesamiento y control formaban la unidad de procesamiento central CPU, pero este diseño contaba con una sola unidad de procesamiento por lo que los programas debían ser escritos para funcionar bajo este diseño y eso implicaba escribir código que se ejecutara de manera secuencial.

Con base en el anterior fundamento pensemos en la siguiente premisa, una computadora con una sola CPU es capaz de ejecutar una sola operación a la vez, pero que sucede si esa operación es muy trabajosa y lleva mucho tiempo de ejecución para esa CPU. Mientras se ejecuta ese proceso las demás operaciones quedarían en pausa, obviamente esto significa que toda la computadora se congelaría y no respondería aparentemente, y todo empeoraría más sí ese proceso contiene un error por lo que la computadora quedaría inutilizable y lo único que puedes hacer es reiniciar. Para solucionar esto se utiliza el concepto de Thread (Hilo).

Entendiendo los Threads

En las versiones actuales del Sistema Operativo Windows, cada aplicación se ejecuta en su propio proceso, un proceso se encarga de separar aplicaciones de otras aplicaciones asignándoles su propia memoria virtual y asegurado que los diferentes procesos no puedan interferir entre sí, cada proceso se ejecuta en su propio hilo. Un Thread (Hilo) es algo así como una CPU virtualizada que permite a una aplicación realizar varias tareas a la vez en paralelo, es parecido al concepto multitarea a nivel del sistema operativo pero los Threads se enfocan en subprocesos que pertenecen a un mismo proceso y la diferencia es que los Threads comparten espacio de memoria y los procesos no.
Para el caso del Sistema Operativo Windows, este administra todos los subprocesos para garantizar que puedan ejecutarse y realizar su trabajo, el SO se encarga de esa administración, de darle tiempo de ejecución en la CPU y cuando este tiempo de ejecución termina, el subproceso se detiene y Windows cambia a otro Thread, esto es a lo que se le conoce como cambio de contexto.
Para poder utilizar Threads en nuestras apliaciones .NET podemos recurrir al espacio de nombres System.Threading en donde encontraremos la clase Thread con la que podremos crear nuevos Threads, gestionar su prioridad y obtener su estado.
Veamos un ejemplo con código C# de como podemos ejecutar un segundo Thread al tiempo que realizamos una operación en el Thread principal de una aplicación de consola.
Crearemos 3 métodos

ReadDataFromIO => este método simula lectura y escritura de archivos, aunque en realidad lo que hacemos es poner el hilo actual en suspensión para simular esa operación de IO.

static double ReadDataFromIO()
{
   // Estamos simulando una E/S poniendo el hilo actual en suspensión.
   Thread.Sleep(5000);
   return 10d;
}

DoIntensiveCalculations => este método simula cálculos matemáticos intensivos, aunque en realidad lo que haremos será hacer divisiones sin sentido solo para efectos de simulación.

static double DoIntensiveCalculations()
{
   // Estamos simulando cálculos intensivos
   // haciendo divisiones sin sentido
   double result = 100000000d;
   var maxValue = Int32.MaxValue;

   for (int i = 1; i < maxValue; i++)
   {
      result /= i;
   }

   return result;
}

RunWithThreads => este método contendrá la ejecución de ambas operaciones y será invocado en el método main de la clase Program.

static void RunWithThreads()
{
   double result = 0d;

   // Crear el hilo para leer desde E/S
   var thread = new Thread(() => result = ReadDataFromIO());

   // Iniciar el hilo
   thread.Start();

   // Guardar el resultado de el calculo en otra variable
   double result2 = DoIntensiveCalculations();

   // Esperar a que el hilo termine 
   thread.Join();

   // Calcular el resultado final
   result += result2;

   // Imprimir el resultado
   Console.WriteLine("El resultado es {0}", result);
}

Ahora en el método Main invocaremos RunWithThreads().

static void Main(string[] args)
{
   RunWithThreads();
}

Independientemente del resultado podemos ver que ambos hilos se ejecutan, inicialmente pasamos un delegado como parámetro en el método constructor de la instancia de la clase Thread, el hilo no se inicia cuando se crea, debemos iniciarlo llamando al método Start(), esto pone en cola este nuevo hilo para su ejecución mientras continúa ejecutando el código en el método actual, seguidamente al ejecutar el método DoIntensiveCalculations se realiza el cálculo intensivo y debe esperar a que el hilo creado anteriormente termine de ejecutarse, esto sucede al invocar al método Join, thread.Join bloquea el hilo actual hasta que el otro hilo termine de ejecutarse y cuando finalice el otro hilo, Join volverá y el hilo actual se desbloqueará. A grandes rasgos de esta manera podemos gestionar los Threads en C#.

Entendiendo el Thread Pool (Grupo de Hilos)

Cuando trabajamos directamente con la clase Thread, creamos un nuevo hilo cada vez y ese hilo que creamos cuando termina su ejecución este muere al finalizar, no obstante esto para el manejador de procesos del sistema operativo representa un golpe al rendimiento al costarle algo de tiempo y recursos. Afortunadamente en C# tenemos la clase static ThreadPool que representa un grupo de hilos que nos permite reutilizar hilos, en lugar de dejar morir un hilo cuando finalice su ejecución se envía de vuelta al Thread Pool donde puede estar para ser reutilizado cada vez que llega una petición. Para utilizarla lo único que debemos hacer es pasar nuestra operación al método QueueUserWorkItem que se encargará de colocar el elemento recibido en una cola administrada por el Thread Pool para que cuando un Thread del Thread Pool este disponible este recogerá el elemento y lo ejecutará hasta su finalización, aunque tenemos un problema debido a que no se sabe cuando el subproceso terminará su trabajo y no hay ningún tipo de Join para bloquear y forzar una espera. Para resolver esto debemos recurrir a la sincronización de recursos pero es algo que no veremos en este Post y debido a que no se recomienda ni tampoco utilizaremos la clase ThreadPool a menudo ya que en su lugar se debe utilizar otras tecnologías como el Task Parallel Library (TPL) que veremos más adelante.
Veamos el ejemplo anterior con código C# pero esta vez utilizando la clase ThreadPool.

static void RunInThreadPool()
{
   double result = 0d;

   // Crear un elemento de trabajo para leer desde E/S
   ThreadPool.QueueUserWorkItem((x) => result += ReadDataFromIO());

   // Guardar el resultado del calculo en otra variable
   double result2 = DoIntensiveCalculations();
   // Esperar a que el Thread termine

   // HACER: Necesitaremos una manera de indicar 
   // cuando el Thread del ThreadPool finalizó la ejecución

   // Calcular el resultado final
   result += result2;

   Console.WriteLine("El resultado es {0}", result);
}

Ahora en el método Main invocaremos RunInThreadPool().

static void Main(string[] args)
{
   RunInThreadPool();
}

Independientemente del resultado de esta manera utilizamos el ThreadPool que viene siendo como una versión 2 de los Hilos.
Algo que debemos saber del Thead Pool es que este limita el número disponible de Threads, esto significa que obtendremos un grado menor de paralelismo que usando la clase Thread a secas. Pero el Thread Pool también tiene muchas ventajas por ejemplo pensemos en un servidor web que atiende peticiones entrantes. Todas esas peticiones llegan en un tiempo y frecuencia que no conocemos. El Thread Pool garantiza que cada petición se agregue a una cola y que cuando exista un Thread disponible este procese la petición. Esto nos asegura que el servidor no se no bloqueará por la cantidad de solicitudes, en cambio si usamos la clase Thread y gestionamos los hilos manualmente podemos derribarlo fácilmente si este recibiera infinidad de peticiones.

Task Parallel Library (TPL)

Una de las deficiencias del uso de subprocesos, hilos, múltiples hilos es que consumen muchos recursos. Cuando se inicia un subproceso este compite con más subprocesos por tiempo de ejecución en la CPU, y gestionar todo esto para el Desarrollador de Software es sumamente complejo, afortunadamente .NET cuenta con el Task Parallel Library (TPL) un conjunto de clases contenidas en el espacio de nombres System.Threading y System.Threading.Task que tienen como finalidad hacer que los Desarrolladores de Software sean más productivos reutilizando clases que optimizan el trabajo de agregar paralelismo y simultaneidad en aplicaciones, TPL se encarga por nosotros de escalar el grado de simultaneidad dinámicamente para usar eficazmente todos los procesadores disponibles en el host, TPL controla la partición del trabajo, la programación de subprocesos en el ThreadPool, permite cancelaciones, administración de estado y otros detalles que preocupan a bajo nivel.

La clase Task (Tarea)

La clase Task fue introducida por Microsoft a partir de .NET Framework 4. Una Task (Tarea) es un objeto que representa un trabajo que debe hacerse, Task puede decir si el trabajo se ha completado, si la operación devuelve un resultado o no, en caso de que si devuelva un resultado Task te permite hacer lo que sea con ese resultado, el Task Scheduler (Planificador de Tareas) es el responsable de iniciar Tasks y administrarlas, por defecto el Task Scheduler utiliza Threads (Hilos) del Thread Pool (Grupo de Hilos) para ejecutar Tasks.
Veamos un ejemplo con Código C#.

const int NUMBER_OF_ITERATIONS = 32;

static void RunTasksCorrected()
{
   double result = 0d;

   Task<double>[] tasks = new Task<double>[NUMBER_OF_ITERATIONS];

   // Creamos una tarea por iteración.
   for (int i = 0; i < NUMBER_OF_ITERATIONS; i++)
   {
      tasks[i] = Task.Run(() => DoIntensiveCalculations());
   }

   // Esperar a que terminen todas las Tareas
   Task.WaitAll(tasks);

   // Recopilar los resultados
   foreach (var task in tasks)
   {
      result += task.Result;
   }

   // Imprimir el resultado
   Console.WriteLine("El resultado es {0}", result);
}

static void Main(string[] args)
{
   RunTasksCorrected();
}

Observemos que podemos lanzar múltiples Tareas a ejecución y esto hará que nuestra aplicación sea más receptiva, ya que sí el Thread que maneja la interfaz de usuario descarga el trabajo a realizar a otro Thread del Thread Pool puede seguir procesando eventos de usuario y garantizar que la aplicación aún se puede usar.
Task se encarga por nosotros de gestionar las condiciones de carrera que ocurren cuando dos o más procesos acceden a un recurso compartido sin control, si esto no se administra o no se toma en cuenta el resultado es erróneo y depende del orden de llegada de la Tarea.

Consejo de expertos y especialistas en C#: No es necesario llamar a WaitAll ya que task.Result bloqueara al autor de la llamada si la Task aún no finalizo de realizar el cálculo. Entonces, si alguna de las tasks no se realiza cuando ingresa al bucle foreach, la petición que llama se bloqueará y esperará a que termine la tarea.

Task Scheduler (Manejador de Tareas)

El Task Scheduler realiza el trabajo de poner en cola las Tareas en subprocesos, la clase TaskScheduler se encarga de esta responsabilidad. Cada vez que se inicia una Task si no se especifica un Scheduler se inicia uno por defecto. Los desarrolladores de software debemos tener en cuenta un aspecto muy importante cuando se crea software que utiliza interfaz gráfica como en proyectos Windows Forms, WPF o Xamarin.Forms, recodemos que la interfaz de usuario solo se puede actualizar mediante el Thread principal que administra la interfaz de usuario, por lo que si una Task necesita actualizar la interfaz de usuario debe hacerlo mediante el Thread que gestiona la interfaz de usuario. Para lograr este objetivo se debe llamar a una de las sobrecargas de StartNew o ContinueWith que toman como parámetro un TaskScheduler y pasarle TaskScheduler
.FromCurrentSynchronizationContext() como valor. Por ejemplo supongamos que tenemos una aplicación Xamarin.Forms que contiene un método llamado UpdateProgressBar() que actualiza un ProgressBar en el Thread de la interfaz de usuario, usaríamos lo siguiente.

Task.Factory.StartNew(UpdateProgressBar, 
                      CancellationToken.None,
                      TaskCreationOptions.None, 
             TaskScheduler.FromCurrentSynchronizationContext());

De esta manera el Thread de la interfaz de usuario actualizará la interfaz de usuario tan pronto como pueda procesarlo.

Parallel Class

El espacio de nombres System.Threading.Tasks también contiene otra clase que podemos utilizar para el procesamiento paralelo. La clase Paralela tiene un par de métodos estáticos: For, ForEach e Invoke: que podemos usar para paralelizar el trabajo.
El paralelismo implica tomar una determinada tarea y dividirla en un conjunto de Tasks relacionadas que pueden ser ejecutadas simultáneamente, esto tampoco significa tengamos que revisar todo nuestro código y reemplazar todos los bucles que tengamos por bucles paralelos. Es recomendable utilizar la clase paralela solo cuando nuestro código no tiene que ejecutarse secuencialmente.
A continuación utilizaremos el método For de la clase Parallel el cuál está definido por la siguiente firma.

public static ParallelLoopResult For<TLocal>(
int fromInclusive,
int toExclusive,
Func<TLocal> localInit,
Func<int, ParallelLoopState, TLocal, TLocal> body,
Action<TLocal> localFinally
)

Haremos una implementación siguiendo el ejemplo anterior pero esta vez con la clase Parallel.

static void RunParallelFor()
{
   double result = 0d;

   // Aquí llamamos al mismo metodo varias veces
   //for (int i = 0; i < NUMBER_OF_ITERATIONS; i++)
   Parallel.For(0, NUMBER_OF_ITERATIONS,
   // Func<TLocal> localInt,
   () => 0d,

   // Func<int, ParallelLoopState, TLocal, TLocal> body,
   (i, state, interimResult) => interimResult + DoIntensiveCalculations(),

   // Paso final despues de los calculos
   // Agregaremos el resultado al resultado final
   // Action<TLocal> localFinally
   (lastInterimResult) => result += lastInterimResult);

   Console.WriteLine("El resultado es: {0}", result);
}

static void Main(string[] args)
{
   RunParallelFor();
}

El tema del rendimiento es algo muy importante a tomar en cuenta en nuestras aplicaciones, y especificamente con el procesamiento en paralelo y multithreading este aumenta cuando tenemos mucho trabajo que realizar que se pueda ejecutar en paralelo. Para cargas de trabajo pequeñas o trabajos que tienen que sincronizar el acceso a los recursos el uso de la clase Parallel puede afectar el rendimiento, la manera de saber si funcionará en nuestros escenarios es medir los resultados con la siguiente y muy sencilla implementación.

static void Main(string[] args)
{
   Parallel.For(0, 10, i =>
   {
      Thread.Sleep(1000);
      Console.WriteLine("Parallel.For: {0} , Task Id: {1}", i, Task.CurrentId);
   });

   var numbers = Enumerable.Range(0, 10);
   Parallel.ForEach(numbers, (i) =>
   {
      Thread.Sleep(1000);
      Console.WriteLine("Parallel.Foreach: {0}", i);
   });
}

Conclusiones

Escribir código que maneja múltiples Threads es altamente díficil debido a que hay muchas cosas a tomar en cuenta como el stack, el heap, datos, memoria, condiciones de carrera y otros aspectos que ocurren a bajo nivel cuando de multithreading se trata.
Aunque existe la clase Thread y ThreadPool es recomendable no utilizarlas directamente, en su lugar Microsoft y expertos en C# recomiendan TPL.
Antiguamente tener un procesador significaba que sólo un subproceso se podía ejecutar a la vez, actualmente con la llegada de los nuevos procesadores multinúcleo y de muchos núcleos, las aplicaciones que se escriben de forma multihilo o asíncrona se benefician intrínsecamente de esas mejoras, mientras que las aplicaciones escritas secuencialmente ignoran los recursos disponibles y hacen que el usuario espere innecesariamente lo que nos lleva a una mala experiencia de usuario.
Un Thread puede verse como una CPU virtualizada.
El uso de varios threads puede mejorar la capacidad de respuesta y permite utilizar múltiples procesadores.
Un objeto Task encapsula un trabajo que debe ejecutarse. Las tareas son la forma recomendada de crear código multithread.
Con TPL podemos debuguear código asíncrono como si fuera síncrono en Visual Studio.
Task Parallel Library (TPL), básicamente proporciona un mayor nivel de abstracción.
El objetivo principal TPL es dar a los desarrolladores la oportunidad de agregar paralelismo y/o simultaneidad a sus aplicaciones.
Una Task es una manera más fácil de ejecutar algo de forma asincrónica y en paralelo en comparación con un subproceso.
TPL es una biblioteca muy extensa por lo que considero que sería oportuno extender este Post en una segunda parte y hablar acerca de async y await palabras clave en el uso de TPL, el procesamiento multithreading y programación asincrona.
TPL también nos proporciona la clase Parallel para paralelizar cargas de trabajo.

Referencias:

Píldoras de C#: Delegates, Métodos Anónimos, Expresiones Lambda y Eventos

Eduardo Barrios — Sun, 01 Nov 2020 21:21:03 +0000

En alguna ocasión te has preguntado como almacenar un método en un tipo de dato de C#, o te has preguntado como pasar un método como parámetro a otro método y como carajos funcionan los eventos. Estás características lenguajes de programación como JavaScript lo hacen a menudo, por su parte C# puede lograr todo esto mediante Delegates. En este Post abordaremos los siguientes puntos sobre delegates en C#.

¿Qué es un Delegate, como creo un Delegate?
Delegates integrados de .NET
Métodos Anónimos
Expresiones Lambda
Eventos
Utilizando Delegates (Xamarin Forms, ASP.NET Core WebApi)

Qué es un Delegate

Un delegate en C# es un tipo de dato como lo es una estructura, o una clase, estos tipos definen propiedades, métodos y algunas veces eventos, por su parte los delegates se encargan de referenciar métodos que coincidan con una firma compatible determinada por los parámetros de entrada y tipo de retorno. Podemos comparar los delegates con los punteros de C++, un delegate de C# apunta a la dirección en memoria de 1 o más métodos esto gracias a la Multidifusión que permite anidar métodos a una instancia de un tipo delegate, los delegates de C# nos permiten crear instancias de un tipo delegate y dejar que apunte a otro método y así mismo invocar el método a través de la instancia del tipo delegate, esto es muy útil para poder pasar métodos como parámetros hacía otros métodos o para poder crear manejadores de Eventos que no son más que métodos que se invocan mediante delegates.
Imaginemos los siguientes casos, una aplicación de escritorio desarrollada con Windows Form poseé una interfaz gráfica con elementos Button, Combobox, TextBox, etc, el usuario puede realizar acciones presionando click sobre un Button o cualquiera de los otros elementos visuales, la acción de realizar un click desencadena un Evento, aquí entran los delegates ya que podemos manejar ese evento y hacer múltiples cosas mediante un manejador de eventos que se suscriba al Evento lanzado, lo importante en este aspecto es que fue un delegate el que invoco el Evento.
Veamos el caso de una Aplicación Móvil desarrollada con Xamarin Forms, supongamos que tenemos un Content Page que internamente contiene un ListView con objetos genéricos, la acción de realizar un Tap sobre cualquier item o Swipe desencadenará un Evento y es aquí donde otra vez vemos delegates en acción.
C# es un lenguaje de programación fuertemente tipado y muchos de los tipos contenidos dentro de los Assemblies de DotNet funcionan entorno a delegates.
Los delegates de C# podemos crearlos personalizados es decir crear nuestros propios tipos definiendo una firma especifica o podemos reutilizar los propios delegates de DotNet que veremos más adelante.

Veamos como crear un tipo delegate, la siguiente sintaxis define su estructura

[identificador de acceso] delegate [Tipo de retorno] [Nombre del Delegate]([Parámetros de entrada]);

Con base en la sintaxis anterior crearemos un delegate que apunte a métodos con coincidan con una firma determinada.

public delegate int CalculateDelegate(int x, int y);

Mejores prácticas: Algunos programadores agregan la palabra Delegate al final del nombre del tipo Delegate. Esto es muy común pero no es universal tampoco obligatorio.

Ahora necesitamos métodos para almacenar en nuestro tipo Delegate y hacer uso del tipo Delegate para referenciar esos métodos.

public int Add(int x, int y)
{
   return x + y;
}

public int Multiply(int x, int y)
{
   return x * y;
}

public void TestDelegate()
{
   CalculateDelegate instanceDelegate= Add;
   Console.WriteLine(instanceDelegate(5, 4)); // Salida 9

   instanceDelegate = Multiply;
   Console.WriteLine(instanceDelegate(5, 4)); // Salida 20
}

Hemos creado un tipo Delegate muy básico y tenemos una instancia que podríamos utilizar para presentárselo a un método como argumento. Como podemos observar el código anterior solo instanciamos una vez el tipo Delegate y la segunda vez asignamos un segundo método sin nada más, esto gracias a que desde C# 2.0 se agregó la creación automática de un nuevo delegate cuando se asigna un grupo de métodos a un tipo delegate.

Otra característica importante de los Delegates de C# es la multidifusión que permite combinar y anidar métodos a la lista de invocación de una instancia de delegado existente, utilizamos el operador + o += para lograrlo.

public void MethodOne()
{
   Console.WriteLine("Método 1");
} 

public void MethodTwo()
{
   Console.WriteLine("Método 2");
} 

// Definir el Tipo Delegate
public delegate void FunctionDelegate();

public void TestMulticast()
{
   FunctionDelegate d = MethodOne;
   d += MethodTwo;

   d();
}

// Salida:
// Método 1
// Método 2

Nota: La multidifusión de los Delegates es la característica que permite suscribirse a Eventos y manejadores de Eventos.

Delegates integrados de .NET

.NET define dos tipos de delegates genéricos(Action y Func) ambos los podemos utilizar para evitar definir nuestros propios delegates.

Delegate Action

El Delegate genérico Action representa un método que devuelve void. Diferentes versiones de Action toman entre 0 y 16 parámetros de entrada, a menos que necesitemos un delegate que tome más de 16 parámetros de entrada y devolver void se recomienda utilizar Action.
Veamos el ejemplo anterior de los métodos Add y Multiply que toman dos tipos int como parámetros de entrada y en este caso devuelven void. Cambiaremos la firma de ambos métodos.

public void Add(int x, int y)
{
   Console.WriteLine(x + y);
}

public void Multiply(int x, int y)
{
   Console.WriteLine(x * y);
}

public void TestDelegate()
{
   Action<int, int> action = Add;
   action(5, 4); // Salida 9

   action = Multiply;
   action(5, 4); // Salida 20
}

Nota: Action en su declaración toma dos tipos int, ambos hacen referencia a los dos parámetros de entrada tipo int que son requeridos y deben coincidir con la firma del método y el delegate.

Delegate Func

El Delegate Func es otro de los tipos integrados de .NET que representa un método que devuelve un valor, como el caso de Action, Func tiene múltiples versiones que toman entre 0 y 16 parámetros de entrada y a menos que no sea necesario presentar más de 16 parámetros de entrada y devolver un valor se recomienda utilizar el tipo delegate Func. Veamos el ejemplo anterior de los métodos Add y Multiply que toman 2 parámetros de entrada tipo int y devuelven un int como resultado, para esto regresaremos a la firma de ambos métodos como fueron definidos en un principio.

public int Add(int x, int y)
{
   return x + y;
}

public int Multiply(int x, int y)
{
   return x * y;
}

public void TestDelegate()
{
   Func<int, int, int> func = Add;
   Console.WriteLine(func(5, 4)); // Salida 9

   func = Multiply;
   Console.WriteLine(func(5, 4)); // Salida 20
}

Nota: Func en su declaración toma 3 tipos int, los primeros dos tipos int representan la cantidad de parámetros de entrada, en este caso son 2 valores de tipo int, el tercer int en la declaración del delegate Func hace referencia al tipo a devolver, el resultado de la operación será un int y la firma de ambos métodos especifican que deben devolver un tipo int.

Delegate Predicate

Predicate es otro Delegate integrado de .NET como lo son Action y Func. Predicate está definido por la siguiente firma.

public delegate bool Predicate<in T>(T obj);

Predicate representa un método que contiene un conjunto de criterios a verificar y valida si el parámetro pasado cumple con esos criterios. Es obligatorio para Predicate pasar un parámetro de entrada y siempre devuelve un booleano true o false.
Veamos un ejemplo para entender como funciona Predicate.
Supongamos que necesitamos validar cuentas de correo electrónico, tenemos una lista de cadenas que contiene múltiples cuentas de correo electrónico, pero entre la lista existen cuentas de correo electrónico no validas, con base en esa primer lista necesitamos crear una segunda lista que contenga solo las cuentas de correo electrónico válidas. Crearemos un Delegate Predicate para lograr este objetivo.

// Método que pasaremos al Delegate Predicate
// Este método devolverá true o false dependiendo si el email es válido
public bool EmailIsValid(string email)
{
   string pattern = @"^([\w-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([\w-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$";
   return Regex.IsMatch(email, pattern);
}

public void TestDelegate()
{
   // Lista de emails
   var emails = new List<string>()
           {
                "admin@gmail.com",
                "admin@gmail",
                "2gmail.com",
                "test@hotmail.com"
            };

   // Creamos el Predicate
   Predicate<string> predicate = new Predicate<string> (EmailIsValid);

   // Utilizamos el Predicate para crear una nueva lista con emails válidos
   var validEmails = emails.FindAll(predicate);

   // Recorremos la nueva lista
   foreach (var email in validEmails)
   {
      Console.WriteLine(email);
   }
}

// El resultado es:
// admin@gmail.com
// test@hotmail.com

Métodos Anónimos

Los métodos anónimos no son más que métodos sin nombre. En lugar de crear métodos como normalmente lo hacemos creamos un delegado que haga referencia al código que debería contener el método tradicional internamente, con esto podremos utilizar ese delegado como si fuera una variable de delegado que contiene una referencia al método. A continuación la sintaxis correcta para crear un método anónimo.

delegate([parámetros de entrada]){ Código; }

Modifiquemos el caso anterior pero ahora en lugar de pasar como argumento el método tradicional que cumple con la firma de un Predicate, pasaremos la definición del método como argumento y como un método anónimo.

public void TestPredicate()
{
   Predicate<string> predicate = new Predicate<string>(
                     delegate(string email)
                     {
                       string pattern = @"^([\w-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([\w-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$";
                       return Regex.IsMatch(email, pattern);
                      });

   var validEmails = emails.FindAll(predicate);

   foreach (var item in validEmails)
   {
     Console.WriteLine(item);
   }
}

Expresiones Lambda

Suelen suceder casos en los que la firma completa de un método puede ser más código que el propio cuerpo del método, también hay situaciones en las que necesitamos crear un método completo solo para usarlo en un delegado. Para esos casos Microsoft agregó algunas características importantes y útiles en C#. En C# 2.0 se agregaron los métodos anónimos, en C# 3.0 mejoraron aún más cuando se agregaron las expresiones lambda. Las expresiones lambda nos permiten utilizar una sintaxis concisa y más corta para que de otra forma podamos escribir métodos anónimos.
A continuación la sintaxis correcta para escribir una expresión lambda.

() => expression;

Nota: Los paréntesis vacíos representan la lista de parámetros vacía tomada por el método anónimo, => indica que se trata de una expresión lambda, en este caso la expresión lambda es de una sola instrucción, si el método necesita más de una instrucción se deben agregar {} de la siguiente manera.

() => 
{
  // Instrucción 1;
  // Instrucción 2;
}

Nota Importante: Pasar parámetros de entrada a un método anónimo con sintaxis de expresión lambda es sumamente sencillo, debemos agregar los parámetros dentro de los paréntesis de la expresión, cuando es un solo parámetro podemos omitir los paréntesis y escribir únicamente el nombre del único parámetro. Otro punto importante es el tipo de los parámetros podemos agregarlos o dejar que la característica de inferencia de tipos de C# haga el trabajo.

// Pasando un solo parámetro
Action<string> action1 = (nombre) => Console.WriteLine($"Hola {nombre}");

// Pasando un solo parámetro sin los paréntesis
Action<string> action2 = nombre => Console.WriteLine($"Hola {nombre}");

// Pasando dos parámetros sin especificar el tipo
Action<int, int> action3 = (a, b) => Console.WriteLine(a + b);

// Pasando dos parámetros especificando el tipo
Action<int, int> action4 = (int a, int b) => Console.WriteLine(a + b);

Mejores Prácticas: Incluir los paréntesis aunque solo necesitemos un parámetro de entrada para una expresión lambda es una buena práctica ya que hace más legible el código. Naturalmente las expresiones lambda ya son bastante confusas por lo que muchos desarrolladores las incluyen aunque no sean necesarias.

Eventos

Los eventos permiten que exista una comunicación entre objetos y un programa para indicar cuando algo interesante ha sucedido o se ha bloqueado, por ejemplo un objeto de correo electrónico podría generar un evento para indicar al programa que ha recibido un mensaje nuevo.
Una solución reutilizable para problemas recurrentes con base en eventos en el desarrollo de aplicaciones es el de Editor-Suscriptor, consiste en suscribirse a un evento y luego notificar cuando el editor del evento plantea un nuevo evento, naturalmente esto se usa para establecer un acoplamiento flojo en componentes de una aplicación.
A continuación un ejemplo sencillo del patrón Editor-Suscriptor y Eventos.

public class Editor
{
   public event Action OnChange = delegate { };

   public void Raise()
   {
     OnChange();
   }
}

public void TestEvents()
{
  Editor editor = new Editor();
  editor.OnChange += () => Console.WriteLine("Evento generado en el método 1");
  editor.OnChange += () => Console.WriteLine("Evento generado en el método 2");

  editor.Raise();
}

Utilizando Delegates

Xamarin Forms

Pensemos en el siguiente escenario. Tenemos una aplicación móvil desarrollada con Xamarin Forms que contiene un control Entry que recibe el nombre del usuario y existe un control Button que al presionarlo muestra un Dialogo que saluda al usuario, pensando como desarrollador Xamarin lo resolvemos haciendo un Binding a la propiedad Text del Entry y otro Binding a la propiedad Command del control Button, una vez que tenemos capturado el valor del Entry creamos el Command que se ejecutara cuando el usuario presione el Button y nuestro Command quedaria de la siguiente manera.

private string name;
public string Name
{
   get { return name; }
   set { name = value; }
}

public ICommand ExecuteCommand
{
   get
   {
     return new Command(ExecuteMethod);
   }
}

private void ExecuteMethod()
{
   Application.Current.MainPage.DisplayAlert("Delegates App", $"Hola: {this.Name}", "Ok");
}

Está es la manera más habitual para resolver el problema planteado, pero observemos la nueva instancia de Command, Command según la documentación oficial de Microsoft todas las sobrecargas de constructores reciben delegates como parámetros los ya conocidos anteriormente tipos integrados por .NET Action y Func. Lo que estamos haciendo es utilizar delegates y tal vez ves no lo sabias.

Podemos variar la implementación tradicional pero antes analizar si en lugar de escribir un método completo con una firma más extensa que el propio cuerpo del método o si el delegado que necesita nuestro Command solo se utilizará una vez podemos pasar como parámetro al Command un método anónimo como tal o con sintaxis de expresión lambda como lo haremos a continuación.

private string name;
public string Name
{
   get { return name; }
   set { name = value; }
}

public ICommand ExecuteCommand
{
   get
   {
     // Pasando el delegate como método anónimo a la nueva instancia de Command
     return new Command(delegate() { Application.Current.MainPage.DisplayAlert("Delegates App", $"Hola: {this.Name}", "Ok"); });
   }
}

private string name;
public string Name
{
   get { return name; }
   set { name = value; }
}

public ICommand ExecuteCommand
{
   get
   {
     // Pasando el delegate como método anónimo con sintaxis lambda a la nueva instancia de Command
     return new Command(() => { Application.Current.MainPage.DisplayAlert("Delegates App", $"Hola: {this.Name}", "Ok"); });
   }
}

ASP.NET Core WebApi

Pensemos en el siguiente escenario. Tenemos un WebApi desarrollado con DotNet Core con una implementación genérica del patrón Repository y UnitOfWork. Esta implementación cuenta con un método Get que devuelve una lista genérica de objetos después de heredar implementaciones en una clase abstracta y no recibe ningún parámetro de entrada. El método Get de momento solo devuelve una lista mediante un contexto de Entity Framework, el nuevo requerimiento es que debemos poder agregar condiciones Where pasadas como argumento y como expresión lambda al método Get para poder filtrar los objetos por condiciones genéricas, otro requerimiento es poder ordenar esa lista pasando una expresión lambda como argumento al método Get y por último agregar Includes para obtener información adicional con objetos relacionados mediante sus propiedades de navegación.
Necesitamos pasar expresiones lambda como argumentos al método Get, bueno pensemos en delegates, realmente podría escribir un tipo delegate personalizado, pero considero que no es necesario y podría aprovechar la existencia de los tipos integrados de .Net. Con base en los requerimientos necesitamos devolver un valor y necesitamos pasar parámetros pensemos en resolver la problemática con el Delegate Func, la implementación con los nuevos requermientos quedaría de la siguiente manera.

public interface IGenericRepository<T> where T : class
{
   IEnumerable<T> Get(Expression<Func<T, bool>> whereCondition = null, 
                      Func<IQueryable<T>, IOrderedQueryable<T>> orderBy = null, 
                      string includeProperties = string.Empty);
}

public abstract class GenericRepository<T> : IGenericRepository<T> where T : class
{
   private readonly IUnitOfWork _unitOfWork;

   public GenericRepository(IUnitOfWork unitOfWork)
   {
      _unitOfWork = unitOfWork;
   }

   public IEnumerable<T> Get(Expression<Func<T, bool>> whereCondition = null,
                         Func<IQueryable<T>, IOrderedQueryable<T>> orderBy = null,
                         string includeProperties = string.Empty)
   {
      IQueryable<T> query = _unitOfWork.Context.Set<T>();

      if (whereCondition != null)
      {
         query = query.Where(whereCondition);
      }

      foreach (var includeProperty in includeProperties.Split(new char[] { ',' }, StringSplitOptions.RemoveEmptyEntries))
      {
         query = query.Include(includeProperty);
      }

      if (orderBy != null
         return orderBy(query).ToList();

      else
         return query.ToList();         
   }
}

Hemos agregado el Delegate Func a la firma del Método Get para cumplir los requerimientos, ahora vamos a probar y para eso necesitamos heredar del Repositorio Genérico.

// Modelo Product necesario para una implementación de un CustomRepository
public class Product
{
   public int ProductID { get; set; }
   public string Description { get; set; }
   public double Price { get; set; }
   public DateTime Date { get; set; }
}

public interface IProductRepository: IGenericRepository<Product>
{ }

// Implementación del CustomRepository
public class ProductRepository : GenericRepository<Product>, IProductRepository
{
   public ProductRepository(IUnitOfWork _unitOfWork)
   : base(_unitOfWork)
   { }
}

Con los requerimientos completados podemos recuperar objetos según cualquier condición, ordenar por cualquier propiedad del modelo e incluir relaciones.
Recuperemos los productos que tengan fecha de hoy, ordenados por su precio del más alto hasta el más bajo y sin ninguna relación, el siguiente código realiza esa tarea.

// Prueba del método Get con los nuevos requermientos
public class TestDelegateWebApi
{
   private readonly IProductRepository _customRepository;
   public TestDelegateWebApi(IProductRepository customRepository)
   {
      this._customRepository = customRepository;
   }

   public void GetProducts()
   {
      var products = this._customRepository.Get(product => product.Date == DateTime.Now, product => product.OrderByDescending(p => p.Price), string.Empty);
   }
}

Conclusiones

Es importante saber como crear nuestros propios tipos delegados pero también es importante evitarlo y según nuestras necesidades debemos reutilizar los tipos integrados de .NET.
Los delegados forman la base del sistema de eventos en C#.
Escribir métodos de manera anónima o como expresión lambda es opcional y depende del programador.
Los eventos en C# no son propios de un tipo de proyecto de .NET sino del lenguaje C# como tal.
Microsoft recomienda que todos los eventos proporcionen dos parámetros: el objeto que genera el evento y otro objeto que proporciona argumentos que son relevantes para el evento. El segundo objeto debe ser de una clase derivada de la Clase EventArgs.

Referencias:

Code Snippets Entity Framework Core para Xamarin Forms

Eduardo Barrios — Mon, 29 Jun 2020 14:18:02 +0000

Este Post forma parte del Xamarin Month 2020 una iniciativa de Luis Matos, con un enfoque en Code Snippets útiles en el desarrollo de aplicaciones móviles con Xamarin Forms y Visual Studio ya sea para Windows o Mac. Puedes revisar el resto de contribuciones realizadas por increíbles autores, profesionales y miembros de la comunidad de Xamarin en el siguiente enlace => XamarinMonth.

Entity Framework Core es el ORM favorito de muchos desarrolladores de software .NET, personalmente me parece genial y lo utilizo muy a menudo, es por eso que quiero compartir con contigo algunos Code Snippets que te podrían ser útiles. Cuando de utilizar Entity Framework Core se trata siempre estamos obligados a escribir un Contexto de Datos que se encargará de gestionar la conexión a la Base de datos, además de utilizar el Dependency Service de Xamarin Forms para implementar funcionalidades especificas de cada plataforma.

Los Code Snippets que crearemos en este Post serán:

Contexto de Datos AppDbContext.cs
Interface de Configuración para obtener el Directorio de BD de cada plataforma IConfigDataBase.cs
Implementaciones especificas de Android y iOS ConfigDataBase.cs

Creando el primer Code Snippet

Para crear Code Snippets para Visual Studio en Windows lo que necesitamos es crear un archivo .xml, llenar los elementos correspondientes y agregar el código.
La Documentación oficial de Microsoft nos proporciona un archivo .xml que contiene la plantilla básica para crear nuestro primer fragmento de código.

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet Format="1.0.0">
        <Header>
            <Title></Title>
        </Header>
        <Snippet>
            <Code Language="">
                <![CDATA[]]>
            </Code>
        </Snippet>
    </CodeSnippet>
</CodeSnippets>

Code Snippet AppDbContext.cs

Crearemos un archivo llamado DbContext.snippet en la siguiente ruta %USERPROFILE%\Documents\Visual Studio 2019\Code Snippets\Visual C#\My Code Snippets, con base en la plantilla anterior llenaremos los elementos y agregaremos el código.

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet Format="1.0.0">
        <Header>
            <Title>DbContext</Title>
            <Author>Eduardo Barrios</Author>
            <Description>Crea un Contexto de Datos Entity Framework Core para Xamarin Forms.</Description>
            <Shortcut>dbcontext</Shortcut>
        </Header>
        <Snippet>
            <Code Language="CSharp">
                <![CDATA[
                public class AppDbContext : DbContext
                {
                    string DbPath = string.Empty;

                    public AppDbContext(string dbPath)
                    {
                        this.DbPath = dbPath;
                    }     

                    // TODO: Declarar los objetos del modelo

                    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
                    {
                        optionsBuilder.UseSqlite("Filename="+DbPath);
                    }
                }
                ]]>
            </Code>            
          <Imports>
            <Import>
              <Namespace>Microsoft.EntityFrameworkCore</Namespace>
            </Import>
          </Imports>
        </Snippet>
    </CodeSnippet>
</CodeSnippets>

Probando Code Snippet AppDbContext

Para probar este code snippet debemos crear una nueva clase llamada AppDbContext para que coincida con el nombre de la clase que creará el code snippet, puedes nombrar de otra manera la clase del contexto y cambiarla en el código del fragmento como te guste.
Borramos los using, la clase completa y solo dejaremos el namespace.

Escribimos el shorcut dbcontext, dbcontext hace referencia al tag shorcut que definimos en el archivo .xml, podemos notar que el intellisense de Visual Studio nos muestra información del Code Snippet que fue definida en el mismo archivo DbContext.snippet

Presionamos la tecla TAB dos veces y veremos como el code snippet funciona correctamente y crea el código predefinido.

Interface de Configuración IConfigDataBase

Repetimos los pasos anteriores para crear el code snippet que nos permitirá crear una interface en el proyecto .NET Standard para su posterior implementación en cada plataforma.

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet Format="1.0.0">
        <Header>
            <Title>Xamarin-IConfigDataBase</Title>
            <Author>Eduardo Barrios</Author>
            <Description>Crea una Interface para Configuración de Base de Datos SQLite (Dependency Service).</Description>
            <Shortcut>iconfiguration</Shortcut>
        </Header>
        <Snippet>
            <Code Language="CSharp">
                <![CDATA[
                public interface IConfigDataBase
                {
                    string GetFullPath(string databaseFileName);
                }
                ]]>
            </Code>                      
        </Snippet>
    </CodeSnippet>
</CodeSnippets>

Crearemos una nueva Interface que por convención se llamará IConfigDataBase.cs, seguidamente escribimos el shorcut iconfiguration que definimos previamente en el code snippet.

Presionamos dos veces la tecla TAB y verificamos que nuestro code snippet funciona correctamente.

Code Snippets implementaciones Android y iOS

En los siguientes fragmentos de código agregaremos el código correspondiente para el método GetFullPath(string databaseFileName) y no para la clase completa debido a que debemos implementar la interface creada en el proyecto .NET Standard y el nombre puede ser arbitrario según sea tu decisión y su namespace puede variar.

Android

Repetimos el proceso anterior, creamos el archivo con extensión .snippet y lo nombraremos GetFullPathAndroid.snippet, lo guardamos en la ruta correspondiente.

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet Format="1.0.0">
        <Header>
            <Title>Xamarin-ConfigDataBase</Title>
            <Author>Eduardo Barrios</Author>
            <Description>Crea el método GetFullPath para obtener la ruta de BD en Android (Dependency Service).</Description>
            <Shortcut>getfullpathandroid</Shortcut>
        </Header>
        <Snippet>
            <Code Language="CSharp">
                <![CDATA[                
                public string GetFullPath(string databaseFileName)
                {
                    return Path.Combine(System.Environment.GetFolderPath(System.Environment.SpecialFolder.Personal), databaseFileName);
                }                        
                ]]>
            </Code> 
            <Imports>
                <Import>              
                  <Namespace>System.IO</Namespace>
                </Import>
            </Imports>                     
        </Snippet>        
    </CodeSnippet>
</CodeSnippets>

Posterior a guardar el archivo .snippet podremos comprobar que el intellisense de VS nos muestra la opción y la información de nuestro code snippet.

Presionamos la tecla TAB dos veces para comprobar el correcto funcionamiento de nuestro code snippet.

iOS

Repetimos el proceso anterior, en este caso llamaremos GetFullPathIOS.snippet a nuestro archivo .snippet y lo guardamos en la ruta correspondiente.

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet Format="1.0.0">
        <Header>
            <Title>Xamarin-ConfigDataBase</Title>
            <Author>Eduardo Barrios</Author>
            <Description>Crea el método GetFullPath para obtener la ruta de BD en iOS (Dependency Service).</Description>
            <Shortcut>getfullpathios</Shortcut>
        </Header>
        <Snippet>
            <Code Language="CSharp">
                <![CDATA[                
                public string GetFullPath(string databaseFileName)
                {
                    return Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), "..", "Library", databaseFileName);
                }                        
                ]]>
            </Code> 
            <Imports>
                <Import>              
                  <Namespace>System.IO</Namespace>
                </Import>
            </Imports>                     
        </Snippet>        
    </CodeSnippet>
</CodeSnippets>

Ya podemos utilizar el code snippet.

Presionamos la tecla TAB dos veces para comprobar el correcto funcionamiento de este code snippet.

Nota: No olvidar implementar la interface creada en el proyecto .NET Standard y exportar el assembly [assembly: Dependency(typeof(ConfigDataBase))] sobre la línea del namespace de cada implementación, puedes crear un code snippet para esto si lo requieres aunque yo lo considero innecesario.

Conclusión

Los Code Snippet son útiles para ser más productivos ya que nos permiten encapsular bloques de código que usamos muy a menudo y reutilizarlo mediante un comando de menú contextual o una combinación de teclas de acceso rápido.

Puedes crear Code Snippet para Visual Studio for Mac en el siguiente link:
https://docs.microsoft.com/en-us/visualstudio/mac/snippets?view=vsmac-2019

Para Windows utiliza el siguiente link:
https://docs.microsoft.com/es-es/visualstudio/ide/walkthrough-creating-a-code-snippet?view=vs-2019

En el siguiente Link encontrarás los archivos creados en este post

EbarriosCode / CodeSnippetsEFCoreXamarinForms

¿Qué demonios es Docker y Docker-Compose? y cómo Dockerizar Dotnet Core WebApi y SQL Server en un ambiente de desarrollo ideal

Eduardo Barrios — Mon, 15 Jun 2020 00:55:12 +0000

A menudo que avanzamos en esta extensa curva de aprendizaje en el mundo de la ingeniería y desarrollo de software, nos encontramos con problemas que debemos resolver, algunos muy típicos y otros no tanto. En este post me enfocaré en abordar algunos problemas relacionados al ciclo de vida del desarrollo del software como:

¿Por qué nadie usa la versión estable de DotNet? - El arquitecto
En mi máquina funcionaba. - El desarrollador
Copie los archivos a donde dijiste, si no funciona es tu problema - Operaciones

Vamos a centrarnos en una de las tantas tecnologías de moda en la industria del software llamada Docker.

Que abordaremos en este post

¿Qué demonios es Docker?

Máquinas Virtuales

Contenedores de Docker

Docker-Compose

Utilizar Docker-Compose para crear un ambiente Multi-Contenedor con ASP.NET Core y SQL Server

Requisitos

Docker-Desktop

Visual Studio 2019

Docker

Una plataforma abierta para desarrollar, enviar y ejecutar aplicaciones que te permite empaquetar tu proyecto con todas sus dependencias únicamente necesarias en un simple binario, de forma totalmente aislada al resto de aplicaciones que puedan convivir en el mismo host.
Docker es muy útil para desarrolladores y administradores de sistemas para compilar, ejecutar y compartir aplicaciones en contenedores.
Los contenedores no son nuevos el concepto data desde 1979 y aunque Docker como tal salió en 2013 hoy en día sigue siendo tendencia y su uso para implementar fácilmente aplicaciones es totalmente genial.
El concepto de utilizar contenedores es cada vez más popular debido a que nos ofrecen múltiples beneficios y características como las siguientes:

Flexibles: Incluso las aplicaciones más complejas se pueden contenerizar.
Ligeros: Los contenedores aprovechan y comparten el Kernel del host, haciéndolos mucho más eficientes en términos de recursos del sistema que las máquinas virtuales.
Portables: Puedes compilar localmente, implementar en la nube y ejecutar en cualquier lugar.
Acoplados holgadamente: Los contenedores son altamente autosuficientes y encapsulados, lo que te permite reemplazar o actualizar uno sin interrumpir a otros.
Escalables: Puedes aumentar y distribuir automáticamente réplicas de contenedor en un centro de datos.
Seguros: Los contenedores aplican restricciones y aislamientos agresivos a los procesos sin ninguna configuración necesaria por parte del usuario.

Nota: Los contenedores y las máquinas virtuales a menudo son muy comparados debido a que son tecnologías que nos ofrecen un mecanismo de virtualización, aunque nos pueden servir para lo mismo presentan algunas notables diferencias, analicemos cada uno por separado y al final tendremos una conclusión sobre un contenedor versus una máquina virtual.

Máquinas Virtuales (VM)

Una VM nos provee de un sistema operativo completo funcionando de manera aislada sobre otro sistema operativo completo.
La tecnología de VMs permite compartir hardware entre varios sistemas operativos al mismo tiempo.
A continuación un esquema simplificado de arquitectura de VMs:

Léelo de abajo a arriba

Es lógico pensar que tras bambalinas siempre tiene que existir infraestructura que lo soporte todo, esta puede ser tu computadora personal para desarrollo, un servidor onpremise en tu data center o algún servicio de infraestructura en la nube IaaS que ofrecen distintos proveedores como Azure, AWS, Google Cloud, Digital Ocean, etc, para esto existen múltiples opciones pero al final se trata siempre de "infraestructura": máquinas físicas sobre las que se ejecutan las VMs.
No obstante para que las máquinas virtuales puedan ejecutarse es necesario otro componente importante que está por encima del S.O. llamado hipervisor, un software especializado para exponer los recursos de hardware del host, de modo que puedan ser utilizados por otros sistemas operativos, obviamente esto incluye CPUs, memoria, tarjeta de red, espacio de almacenamiento en disco y el resto del hardware.
En conclusión la tarea del hypervisor es engañar a un sistema operativo convencional para que crea que se está ejecutando sobre una máquina física.
Los hipervisores que probablemente conozcas porque son muy comunes y son los que personalmente conozco:

VirtualBox
Hyper-V
VMWare

Contenedores de Docker

Los contenedores por su parte tienen un enfoque totalmente distinto al de las VMs. Si bien es cierto tratan también de aislar aplicaciones y de generar un entorno replicable, portable y estable para la ejecución de procesos, esto gracias a los namespaces y control groups de Linux.
Los contenedores en lugar de ejecutar un sistema operativo completo lo que hacen es compartir los recursos del propio sistema operativo "host" sobre el que se ejecutan.

A continuación el esquema equivalente al de VMs, para el caso de contenedores:

Visualmente podemos notar que solo desaparece la capa del sistema operativo huésped (Guest Host), y se sustituye el hipervisor por el motor de Docker, sin embargo las diferencias son grandes.
Docker se encarga de ejecutar y gestionar los contenedores, pero en lugar de exponer los diferentes recursos de hardware del host, lo que hace es compartir entre todos los contenedores ese hardware, optimizando su uso y eliminando la necesidad de tener n cantidad de sistemas operativos separados para conseguir el aislamiento y garantizar el mismo comportamiento de las aplicaciones contenerizadas en diferentes ambientes.

Otro tema muy importante sobre Docker es su funcionamiento con base en imágenes que se pueden reutilizar entre varias aplicaciones y/o contenedores. Cada una de esas imágenes se puede asimilar como una "capa" que se puede superponer a otras para formar un sistema de archivos que combina todas las capas necesarias.

Ejemplo: Una capa puede contener las bibliotecas o el runtime que necesitamos utilizar, para este ejemplo será el SDK de Dotnet Core, otra con bibliotecas determinadas de las que hace uso nuestra aplicación por ejemplo Entity Framework, Serilog, JWT, etc, y otra capa final con el código fuente de nuestra aplicación. La combinación de todas estas capas nos da como resultado una nueva imagen, única de nuestra aplicación, y con esta nueva y única imagen podemos instanciar y crear uno o varios contenedores.

Nota Importante: Las VMs y los contenedores son tecnologías que persiguen un fin similar, pero con distintos enfoques.

Docker-Compose

Es una herramienta para definir y ejecutar aplicaciones Docker multicontenedor que permite simplificar el uso de Docker a partir de archivos YAML, de está forma es mas sencillo crear contendores que se relacionen entre sí, conectarlos, habilitar puertos, volumenes, etc. Nos permite lanzar un solo comando para crear e iniciar todos los servicios desde su configuración(YAML), esto significa que puedes crear diferentes contenedores y al mismo tiempo diferentes servicios en cada contenedor, integrarlos a un volumen común e iniciarlos y/o apagarlos, etc. Este es un componente fundamental para poder construir aplicaciones y microservicios.
Docker-Compose funciona en todos los entornos: production, staging, development, testing, así como flujos de trabajo basados en Continuous Integration(CI).
Si quieres conocer más acerca de Docker-Compose ve a la documentación oficial https://docs.docker.com/compose/#features

Nota: En este Post utilizaremos docker-compose para lanzar dos contenedores. Uno que contenga todas las dependencias para empaquetar una solución ASP.NET Core WebApi y otro contenedor que contenga las dependencias necesarias para nuestra Base de Datos SQL Server. Mediante docker-compose haremos el enlace de comunicación entre ambos contenedores.

Estoy seguro que hasta este punto ya entendemos lo básico de cómo funcionan ambas tecnologías.

Vamos a centrarnos en crear un entorno ideal de desarrollo con tecnologías Microsoft (Dotnet Core y SQL Server) sobre Docker aprovechando la facilidad que nos proporciona docker-compose sobre el Engine de Docker para realizar tareas programáticamente.

Utilizando Docker-Compose para crear un ambiente Multi-Contenedor con ASP.NET Core y SQL Server

Inicialmente vamos a necesitar una solución ASP.NET Core que vamos a empaquetar en un contenedor de docker, utilizaremos la siguiente solución perteneciente a un Post anterior.

Base de Datos en memoria con ASP.NET Core 3.0 MVC + Entity Framework Core

Eduardo Barrios ・ Nov 7 '19

#csharp #dotnet #database

Nota: Esta solución utiliza una base de datos SQL Server In Memory, en este caso cambiaremos esa característica y vamos a montar SQL Server en un Contenedor de Docker.

Una vez que hemos abierto nuestra solución WebApi en Visual Studio 2019, vamos a situarnos en el proyecto WebApi y vamos a agregar la Compatibilidad con el Orquestador de Contenedores.

Seleccionamos Docker-Compose

Tras pulsar el botón Aceptar empezará el proceso de creación del proyecto Docker-Compose en nuestra solución de Visual Studio, se agregará un archivo llamado Dockerfile en el proyecto WebApi y en segundo plano se hará pull de las imágenes de Docker necesarias para empaquetar nuestra solución.

Examinaremos el nuevo proyecto Docker-Compose recientemente creado.

Nota: Este proyecto consta de 3 archivos.

.dockerignore - Se encarga de ignorar configuraciones o compilados y files que utiliza o crea Docker en tiempo de compilación y/o ejecución que son propios de cada ambiente y que no son necesarios al momento de hacer push al registry de Docker para publicar una imagen, el .dockerignore es similar al uso del .gitignore de repositorios Git.

docker-compose.yml - Es un archivo YAML donde definimos los servicios, redes, volumes y todo lo necesario para crear un ambiente con base en contenedores. Se encarga de buscar instrucciones para ejecutarlas, estas instrucciones contienen toda la configuración que será aplicada a cada contenedor iniciado por ese servicio.
Las instrucciones del docker-compose.yml son equivalentes a pasarle parámetros al comando docker run, de la misma manera las definiciones de las redes y volumes serían semejantes a los comandos docker network create y docker volume create.

A continuación una descripción simple de las principales instrucciones contenidas en el archivo docker-compose.yml

version: Los archivos docker-compose.yml son versionados y es importante indicar la versión a utilizar.
services: Indica los servicios a utilizar, podemos anidar n cantidad de servicios a esta instrucción, cada servicio puede tener cualquier nombre pero como buena práctica lo mejor es dar nombres explícitos. Para nuestro ejemplo utilizaremos dos servicios que representan un WebApi de dotnet core y una base de datos Sql Server.
dockerizingwebapi: Es el nombre de nuestro primer servicio y hace referencia a nuestro WebApi.
container_name: Permite establecer un nombre para un contenedor al que hace referencia el servicio.
image: Permite tagear la imagen que se creará para instanciar el contenedor en el que estará montado el servicio. Es equivalente a utilizar el comando docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG].
build: Se utilizar para indicar el contexto e indicar la ruta del archivo Dockerfile para construir el contenedor del servicio. Posteriormente veremos que es un Dockerfile.
depends_on: Se utiliza para establecer la dependencia y comunicación con otros servicios, en este caso el servicio dockerizingwebapi necesita comunicarse con el servicio database que se encuentra definido posteriormente.
database: Es el nombre de nuestro segundo servicio y hace referencia a la base de datos sql server.
ports: Se utiliza para exponer los puertos necesarios desde el contenedor.
environment: Permite establecer variables de entorno durante el ciclo de vida del contenedor.

docker-compose.override.yml - Expone configuraciones específicas para el entorno de desarrollo. Crea algunas variables de entorno, expone algunos puertos del host y monta algunos volumes.

Nota: Docker-Compose nos permite utilizar múltiples archivos de configuración y personalizar nuestra aplicación con base en Compose para diferentes ambientes o flujos de trabajo con el fin de compartir configuración común.

Ejemplo: Podríamos crear un archivo docker-compose.prod.yml y que exponga configuraciones específicas para un entorno productivo. Lo mismo podríamos hacer con otros ambientes como Staging, Testing, Production, etc. Con esto podemos aprovechar extender esta funcionalidad para replicar entornos y que cada entorno contenga configuraciones propias.

Dockerfile

Para crear contenedores de Docker podemos utilizar varios comandos, descargar imágenes del Registry de Docker con docker pull seguidamente utilizar docker run, y múltiples acciones que podemos realizar con más comandos de Docker.
Un Dockerfile es un archivo de texto plano que contiene todos los comandos de Docker que podríamos ejecutar desde la línea de comandos para crear una imagen y seguidamente instanciar un contenedor con base en esa imagen. Docker nos permite construir imágenes automáticamente ejecutando las instrucciones definidas en un Dockerfile.

Nota: El Dockerfile que crea la plantilla de Visual Studio por defecto viene preparado con multi-stage-builds para poder declarar múltiples FROM en el archivo Dockerfile y garantizar una adecuada optimización de nuestra imagen final de Docker, de esta manera tendremos una imagen limpia con base en otras imágenes de Docker.

Podemos observar que en segundo plano se está haciendo un pull de las imágenes definidas en las instrucciones FROM del Dockerfile, esto hace referencia a dos imágenes de los repositorios de Microsoft.

Ahora crearemos las migraciones para poder crear la estructura de la base de datos dentro del contenedor e inicializar las tablas de la base de datos, para esto tendremos que ejecutar migraciones como lo hacemos normalmente en la consola de administración de paquetes nuget.
Seleccionamos el proyecto WebApi como proyecto de inicio y ejecutamos el comando Add-Migration [nombre_de_la_migración]. Lo anterior creará el Directorio Migrations y las migraciones representadas como clases C#.

Crearemos una clase static y la nombraremos DbInitializer.cs. Esta clase tendrá un método static que recibe como parámetro el contexto de datos que utilizaremos para crear datos iniciales posteriormente a crear las tablas.

Nota: Debemos volver a seleccionar como proyecto de inicio Docker-Compose ya que en este caso no haremos un Update-Database en la consola de administración de paquetes de Nuget de VS, a continuación definiremos un método en la clase Startup.cs que haga esa tarea automáticamente.

Llamaremos a este método UpdateDatabase, lo utilizaremos para aplicar las migraciones en el contenedor y crear datos de inicio en las tablas correspondientes a nuestros modelos en la base de datos dentro del contenedor.

Invocaremos al método anterior en el método Configure() de la misma clase Startup.cs.

Ahora modificaremos la implementación de la inyección de la dependencia de nuestro contexto de datos Entity Framework Core. Reemplazaremos el método UseInMemmoryDatabase por el método UseSqlServer, le pasaremos la cadena de conexión definida en el archivo appsettings.json y haremos un Replace pasando el valor de un EndPoint definido como variable de entorno del contenedor en el archivo docker-compose.override.yml.

Todo está listo es hora de probar, vamos a seleccionar nuestro proyecto Docker-Compose como proyecto de inicio, seguidamente ejecutamos la solución desde Visual Studio. Notaremos que Visual Studio se encarga de lanzar los comandos de Docker y Docker-Compose para utilizar todas las configuraciones.

Ahora iremos a Postman y lanzamos una petición HTTP Get a la url api/Albumes.

Podemos aprovechar las herramientas que nos provee Visual Studio 2019 para obtener información sobre nuestros contenedores.

Como puedes notar en contenedores de Solución tenemos dos contenedores, el primero que contiene un WebApi y el siguiente una Base de datos Sql Server.

También podemos obtener información de nuestros contenedores que están en ejecución lanzando el comando docker ps en cualquier terminal, utilizaré PowerShell.

Nota: Con docker ps obtendremos información de contenedores en ejecución, información como el ID de cada Contenedor, la imagen que utilizó cada contenedor para crearse, los puertos que expone cada contendor.

Conclusiones

Contenedores VS Máquinas Virtuales: Sus diferencias son enormes, tanto en la teoría como en la práctica y es que los contenedores comparten el mismo sistema operativo con el host, conteniendo solo lo estrictamente necesario para ejecutar una Aplicación, Base de Datos, Web Service, un Sistema Operativo, lo que sea que tu quieras empaquetar dentro de un contenedor, mientras que las máquinas virtuales incorporan un sistema operativo completo. Esto afecta directamente y enormemente el rendimiento: al haber menos capas entre el metal (infraestructura) y la aplicación; se ganan milisegundos de latencia preciada. El tiempo de arranque de un contenedor Docker es increíblemente instantáneo.
Los contenedores permiten desplegar aplicaciones rápidamente, arrancarlas, detenerlas más rápido y aprovechar mejor los recursos de hardware.
En cuanto a la utilización de Docker con tecnologías .NET, Visual Studio nos ayuda a ser ágiles en muchos aspectos. Todo lo realizado en este Post puedes hacerlo sin Visual Studio, lanzando los comandos de Docker en cualquier terminal como PowerShell, CMD, Git bash, etc y utilizando cualquier editor de código para modificar tus archivos.
La función principal de Docker-Compose es la creación de infraestructura basada en microservicios, es decir, los contenedores y los vínculos entre ellos. No obstante esta herramienta es capaz de hacer mucho más, como:

Crear Imágenes, si está definido en el Dockerfile



docker-compose build

Escalar contenedores de forma sencilla



docker-compose scale SERVICE=5

Se pueden volver a ejecutar los contenedores que se han detenido



docker-compose up --no-recreate

Docker nos ayuda a crear imágenes y contenedores para nuestras aplicaciones y poder ser más eficientes.
En fin hemos visto y definido qué es y para que nos ayuda Docker y Docker-Compose, la importancia que tiene hoy en día para la implementación de infraestructuras simples que pueden ser para ambientes de desarrollo u otras más complejas que necesitan de alguna forma rápida poder crecer y ser escalables sin que se tengan que hacer tantos procesos manuales.

Link al respositorio en GitHub

EbarriosCode / Docker-Compose-DevEnvironment-WebApi_3.1-with-SQLServer

Guía de explicación sobre este repositorio https://dev.to/ebarrioscode/que-demonios-es-docker-docker-compose-y-como-dockerizar-dotnet-core-webapi-y-sql-server-en-un-ambiente-de-desarrollo-ideal-95a

Referencias

Azure Functions (Serverless) + Entity Framework Core y SQL Azure

Eduardo Barrios — Sat, 16 May 2020 22:48:39 +0000

Azure Functions es una solución Serverless en la nube de Microsoft Azure muy útil y práctica de usar en la actualidad. Por otro lado desarrollar una Function que requiere funcionalidades relacionadas al acceso a datos es obvio que los desarrolladores .NET nos preguntamos en algún momento ¿puedo usar mi ORM favorito Entity Framework Core para acceder a los datos de una Base de Datos SQL Server o SQL Azure desde una Azure Function?
Obviamente la respuesta es Sí, claro que es posible, Microsoft anunció en el Build del año pasado la compatibilidad entre la inserción de dependencias en Azure Functions, esto significa que puede registrarse y utilizar sus propios servicios como parte de las funciones.
Aunque antes de esto ha sido posible utilizar Entity Framework Core en el pasado, la diferencia es que ahora el emparejamiento con la inserción de dependencias ha sido convertido a un ajuste mucho más natural.
Obviamente esto se vuelve más interesante con la llegada de Azure Functions V3 que desde Enero de este año está disponible de manera general, esto significa que ahora es posible compilar e implementar funciones con la versión en tiempo de ejecución 3.0 en producción. Esta nueva versión de Azure Functions ofrece nuevas capacidades, incluida la capacidad de tener como destino .NET Core 3.1
También es altamente compatible con versiones anteriores, por lo que la mayoría de las aplicaciones existentes que se ejecutan en versiones anteriores deben ser capaces de actualizar a la versión 3 y ejecutarse sin ningún cambio en el código.

Que abordaremos en este post

Creación de una Azure Function V3 localmente

Integración de EF Core con Azure Function

Inyección de Dependencias

Migraciones con EF Core y Actualización de Base de Datos

Acceder a datos alojados en SQL Azure

Requisitos

Suscripción de Azure, si no tienes una obtiene una aquí https://azure.microsoft.com/es-es/free/

DotNet Core 3.1 SDK

Visual Studio 2019

Azure Function Core Tools Versión 3

Creando Azure Function

Vamos a crear un proyecto Azure Functions V3 desde Visual Studio 2019 para poder ejecutarla localmente desde nuestra máquina de desarrollo.

Seguidamente vamos a crear la estructura de directorios en la solución.
Quedaría de la siguiente manera:

Nota: La plantilla de una solución de Azure Function en Visual Studio crea por defecto una clase llamada Function1.cs modificaremos ese nombre por FunctionEFCore.cs, también puedes notar que existe una clase Startup.cs pero no te preocupes explicaré el porqué existe esta clase en esta solución.

Integración de EF Core con Azure Function

Debemos instalar los paquetes Nuget necesarios para utilizar Entity Framework Core.

Nota: Microsoft.EntityFrameworkCore.SqlServer es el proveedor de base de datos de Microsoft SQL Server para Entity Framework Core y permite la manipulación de bases de datos mediante el ORM.
Microsoft.EntityFramewrokCore.Tools contiene las herramientas principales de Entity Framework para la consola del Administrador de paquetes NuGet en Visual Studio y habilita los comandos de uso común como:

Add-Migration

Drop-Database

Get-DbContext

Scaffold-DbContext

Script-Migrations

Update-Database

Ahora crearemos los modelos, utilizaré los modelos de Album y Artista que he utilizado en posts anteriores, si has leído alguno seguramente se te harán familiares.

Escribiremos el contexto de datos y agregaremos los modelos correspondientes como propiedades DbSet.

Nota: En este contexto hice un override del método OnModelCreating() para poder crear datos iniciales al momento de crear las migraciones, ejecutar el comando Update-Database y sincronizar la base de datos SQL Azure. Esto creará las tablas en la BD y seguidamente realizará múltiples insert para crear registros.

Previo a correr los comandos para crear las migraciones y hacer un update a nuestra base de datos habilitaremos la creación del DbContext en tiempo de diseño, ya que necesitamos crear una instancia derivada de DbContext.
Para esto implementaremos la interface IDesignTimeDbContextFactory para habilitar los servicios en tiempo de diseño y para este caso en particular las migraciones. Esto aplica únicamente para los tipos de contexto que no tienen un constructor predeterminado público, recordemos que esta no es una solución ASP.NET por eso es necesario.

Seguidamente un paso muy importante es obtener el .dll de la solución en el lugar correcto. Al compilar un proyecto de Azure Functions se organizan algunos artefactos de compilación para crear una estructura de proyecto de function válida, en este proceso el .dll de la solución se mueve a una subcarpeta. Desafortunadamente para las herramientas en tiempo de diseño como las migraciones, esperan que el archivo .dll esté en la raíz del destino de compilación pero esto no sucede así y para resolverlo tendremos que hacer una copia del .dll de la solución a la raíz del proyecto.
Vamos a modificar el archivo .csproj y agregaremos un evento posterior a la compilación para copiar el archivo .dll en la raíz de la solución.

Inyección de Dependencias

Para hacer uso de Inyección de Dependencias (DI) en Azure Function al igual que en una solución de ASP.NET necesitamos acceder al Contenedor de Inversión de control para lograr una inicialización de nuestros servicios.
La plantilla de una solución Azure Function en Visual Studio no incluye una clase Startup.cs por lo que debemos agregarla.
Si no sabes que es Inyección de Dependencias o quieres conocer más detalles y como funciona este patrón de diseño de software te recomiendo leas este post.

Inyección de Dependencias(DI) en ASP.NET Core, mejores prácticas para escribir código reutilizable, escalable y desacoplado

Eduardo Barrios ・ Nov 16 '19

#dotnet #csharp #webdev

Aquí es donde sucede la magia de Inyección de Dependencias. La clase Startup.cs configura los servicios y la canalización de solicitudes de la aplicación además de controlar el Contenedor de Inversión de Controles (IoC) encargado de proveer las instancias de los tipos los cuales le decimos en el inicio de la Aplicación (Startup).
En este punto le dejaremos la responsabilidad de instanciar e inicializar nuestras dependencias tales como el Contexto de Datos y los diferentes servicios específicos de cada tipo de objeto que necesitemos a lo largo del desarrollo de este software.

Nota:

El Método Configure(IFunctionsHostBuilder builder) es donde registramos todos los servicios. IFunctionHostBuilder.Services es el contenedor IoC.

Registrar servicios es exactamente lo mismo que con ASP.NET Core, mediante el uso de los métodos AddScoped, AddSingleton, AddTransient.

La clase Startup debe extender de FunctionsStartup.

Necesitaremos un Servicio de Albumes el cuál tendrá delegadas todas las responsabilidades de manipulación de datos que tengan que ver con objetos tipo Album, este servicio utiliza como dependencia el DbContext, solo debemos preocuparnos por inyectarlo, recordemos que IoC se encargará de instanciarlo e inicializarlo.

Base de Datos SQL Azure

Necesitamos una base de datos de Azure, para esta práctica ya tengo creada una BD en Azure.

Migraciones con EF Core y Actualización de Base de Datos

Antes de iniciar con los comandos para correr las migraciones y hacer el update a la base de datos remota alojada en Azure, debemos establecer una cadena de conexión que sea accesible en tiempo de diseño. Para esto utilizaremos una variable de entorno y correremos el siguiente comando en la consola de administración de paquetes nuget de Visual Studio.

$env:SqlConnectionString="Server={Nombre o IP del Servidor};Initial Catalog={Nombre de la BD};Persist Security Info=False;UserID={UserSQL};Password={Password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"

Ahora debemos correr el comando Add-Migration [Nombre_de_la_migracion] yo le llamaré Initial_Model.
Esta migración creará las instrucciones necesarias para crear las tablas en la bd con base en los modelos que tenemos registrados en el Contexto de Datos y posteriormente insertar datos iniciales, a esta técnica se le denomina Code First.
Tras una ejecución con éxito podremos notar que se agregó un directorio llamado Migrations en la la raíz del proyecto, este directorio contiene las migraciones creadas representadas como clases C#.

Debemos utilizar la migración que acabamos de crear para que los cambios se vean reflejados en la bd, para eso correremos el comando Update-Database.

Para ver los cambios reflejados en la bd vamos a conectarnos mediante Azure Data Studio, únicamente necesitamos el nombre del servidor, un usuario y contraseña para acceder, esto lo encuentras en la administración de la base de datos en el portal de Azure o puedes revisar la cadena de conexión que utilizamos al setear la variable de entorno y que obviamente se obtuvo en el portal de Azure.

Ya podemos ver las tablas creadas en la base de datos y corresponden a los modelos Album y Artista establecidos en nuestra solución.

Ejecutamos dos instrucciones SQL para verificar la existencia de datos que definimos en el método OnModelCreating() en la clase Contexto de Datos.

Acceder a datos alojados en SQL Azure

Ahora lo que debemos hacer es modificar el código en la clase principal FunctionEFCore.cs para utilizar el servicio de Albumes pero para utilizar ese servicio debemos inyectar la dependencia en el método constructor de la clase FunctionEFCore.cs.
Eliminamos el código que crea por defecto la plantilla, eliminamos el static de la clase y el método, invocamos el método GetAsync del Servicio de Albumes y le enviamos ese objeto resultado a una nueva instancia de OkObjectResult que será el resultado a retornar de nuestra Azure Function.

Probaremos localmente nuestra function, posterior a compilar y ejecutar esta solución, vamos a PostMan y enviamos una solicitud Http GET.

Funciona correctamente, el resultado es el esperado.

Conclusión
Esta nueva característica de inserción de dependencias en Azure Functions facilita el trabajo con contextos de base de datos de Entity Framework Core, esto nos da la facilidad de montar un backend en un ambiente de development, test, stage, o production en poco tiempo basándonos en las soluciones Serverless.

Link al Repositorio en Github
https://github.com/EbarriosCode/AzureFunctionV3_EfCore.git

Referencias
https://docs.microsoft.com/en-us/azure/azure-functions/
https://devblogs.microsoft.com/dotnet/announcing-ef-core-3-0-and-ef-6-3-general-availability/
https://docs.microsoft.com/en-us/ef/core/
https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection

Xamarin Forms + Azure Function, desarrollo acelerado y simplificando de aplicaciones Serverless

Eduardo Barrios — Mon, 09 Mar 2020 02:48:18 +0000

Constantemente en el mundo del desarrollo móvil las apps se conectan a un backend y naturalmente pensamos en una aplicación completa y la infraestructura para ejecutarla, pero que sucede en casos en los que no se necesita de una gran API o Servicio Web, optar por el ciclo natural podría volverse tedioso y trabajoso, para abordar esta problemática Microsoft nos ofrece el servicio en la nube denominado Azure Functions (Serverless).
Serverless hace referencia a computación sin servidor, un modelo de ejecución en el que el proveedor en la nube en este caso (Azure) es responsable de ejecutar un fragmento de código mediante la asignación dinámica de los recursos. Y cobrando solo por la cantidad de recursos utilizados para ejecutar el código. El código generalmente, se ejecuta dentro de contenedores sin estado que pueden ser activados por una variedad de eventos que incluyen solicitudes HTTP, eventos de base de datos, servicios de colas, alertas de monitoreo, carga de archivos, eventos programados (trabajos cron), etc. El código que se envía al proveedor en la nube para la ejecución es generalmente en forma de una función. Por lo tanto, serverless se denomina “Funciones como servicio” o “FaaS”.

En este Post crearemos una pequeña y sencilla Azure Function desde el portal web de Azure, esta función recibirá algunos parámetros para procesarlos y devolver un resultado esto hará el trabajo de un API, luego crearemos una aplicación móvil multiplataforma con Xamarin Forms para consumirla.

Problema a resolver con este proyecto: Calcular tu peso ideal
Para calcular el peso ideal hay que saber manejar el Índice de Masa Corporal (IMC), una medida que nos ayuda a detectar si nos encontramos dentro de los valores saludables o no.
La Organización Mundial de la Salud estima que un peso saludable es el que se sitúa entre valores de 18,5 y 24,9.
Los valores inferiores a 18,5 nos indican un peso demasiado bajo.
Si son iguales o superiores a 25 se consideraría ya sobrepeso. Si supera los 30 se trata de obesidad.

El peso ideal se calcula dividiendo el peso en kilogramos por el cuadrado de la altura en metros (kg/m2). Ejemplo: Si una persona pesa 60 kilos y mide 1,50 el resultado final sería 26, 6. Según Aragón, en este ejemplo la persona tendría ligero sobrepeso.
Hay que tener en cuenta que el cálculo del IMC “sólo es válido entre personas de 20 y 65 años y nunca para niños, embarazadas, madres lactantes o personas que realizan mucho deporte o de alta competición”.

Definición de tareas Azure Function y Aplicación móvil
Crearemos una aplicación móvil que calculará el peso ideal de una persona, esta recibirá los datos que necesitamos (peso y altura de una persona). Nuestra función de azure hará el procesamiento por medio de una petición HTTP Post, recibirá los datos serializados como un objeto JSON, realizará la operación para obtener el resultado final IMC para finalmente mostrar ese resultado en nuestra aplicación móvil.

Creando una función de Azure

En primera instancia necesitas una suscripción de Azure, puedes obtener una aquí https://azure.microsoft.com/es-es/free/
Después necesitamos crear el recurso, puedes buscarlo en la barra de búsqueda o en la sección de nuevo recurso, selecciona Azure Function.
Necesitamos completar la información obligatoria para crear nuestra Azure Function.

Una vez completados los datos Azure nos mostrará la información con las características de nuestra Azure Function, pulsamos en crear y esperamos a que se cree el recurso, Azure nos notificará cuando todo este listo.
Una vez creado el recurso necesitamos seguir unos pasos más.
Debemos elegir un entorno de desarrollo, en este caso seleccionamos en el Portal.
Seleccionamos WebHook y API.
Al crear una Azure Function esta se crea con código por defecto, eleminaremos ese código y lo sustituiremos por el siguiente y pulsaremos en el botón Guardar y Ejecutar.

Nota: Puedes encontrar el código para la función de Azure en el repositorio de github. Link al final de post.

Tenemos lista nuestra Azure Function!

Previo a consumirla desde Xamarin Forms haremos una prueba desde un cliente HTTP en este caso PostMan, necesitamos obtener la url para poder realizar la petición HTTP, da click en la opción Obtener la dirección URL de la función.
Ahora vamos a PostMan y utilizamos la Url obtenida en el paso anterior, debemos utilizar el verbo HTTP Post y enviar el objeto JSON en el cuerpo de la petición.

El resultado también es un objeto JSON que contiene una propiedad llamada result, el valor que tiene asignado result es lo que esperamos como respuesta.

Creando App Móvil Xamarin Forms

Para este proyecto utilizaré Visual Studio 2019 Preview, y crearé un proyecto Xamarin Forms 4.3.
Me apoyaré del patrón de arquitectura de Software MVVM para tratar de desacoplar lo máximo posible la interfaz de usuario de la lógica de la aplicación, buscando factorizar el código de la aplicación en las clases correctas y en establecer la interacción de clases entre sí.

Inicialmente estructuraremos los directorios de la Aplicación de la siguiente manera:

Nota: la página que se crea por defecto MainPage.xaml fue movida al directorio Views, no olvidar cambiar el namespace en el archivo MainPage.xaml.cs y modificar la referencia en el archivo xaml.

Seguidamente abrimos el administrador de paquetes nugets para la solución y vamos instalar el nuget Newtonsoft.Json en el proyecto NET-Standard.

Ahora vamos a crear 3 clases en el directorio Models, las clases modelo se llamaran Response, PesoIdealParam y PesoIdealResult.

Response.cs este modelo hace referencia al resultado que obtenemos al realizar una petición HTTP hacia nuestra Azure Function corriendo en Azure, consta de 4 propiedades: IsSucces toma un valor booleano que depende del éxito o excepción al realizar la petición HTTP, Message almacena el mensaje de respuesta al realizar la petición HTTP, StatusCode como toda petición HTTP retorna un StatusCode este se almacena en esta propiedad y por último DataResult un tipo Object que es capaz de almacenar cualquier tipo de objeto o lista de objetos que pueda retornar la petición HTTP.

PesoIdealParam.cs este modelo lo utilizaremos para enviar los valores recibidos en está app, vamos a serializarlos en formato JSON para luego enviarlos a nuestra Azure Function y se encargue de procesarlos, en este punto tendremos 3 propiedades que necesitaremos enviar: el nombre de la persona, el peso en kilogramos y la altura en metros, las propiedades de clase en C# las manejaremos con mayúsculas aunque en nuestra Azure Function están con minúscula, por eso es necesario utilizar las Anotaciones de Datos [Data Annotations] como decorador de cada propiedad de clase, los Data Annotations poseen el nombre de la propiedad como se gestiona en el backend y el nombre en mayúscula en la propiedad de clase es como gestionamos esa propiedad dentro de la app.

PesoIdealResult.cs este modelo únicamente posee una propiedad que se encargará de almacenar el resultado recibido del proceso que realiza nuestra Azure Function.

Ahora crearemos una clase llamada AzureFunctionService.cs en el directorio de Services, aquí encapsularemos la lógica para realizar la petición HTTP hacia nuestra Azure Function mediante un método asíncrono de retorna un Task de Response.

El siguiente paso es crear la clase ViewModel llamada MainViewModel.cs en el directorio ViewModels, este archivo encapsula la lógica de la aplicación encargada de utilizar diferentes clases que contienen diferentes responsabilidades.
MainViewModel.cs contiene las propiedades, atributos, validaciones, uso del servicio para utilizar Azure Function dentro de un método que responde al evento de ejecución dentro de un command de Xamarin Forms.

MainViewModel.cs hereda de BaseViewModel.cs una clase que contiene una implementación de INotifyPropertyChanged con el evento que notificará los cambios de cada propiedad en la ViewModel.

En este paso modificaremos la vista MainPage.xaml e inicialmente es necesario agregar la referencia al namespace al que pertenece la clase MainViewModel.cs y seguidamente establecemos el Binding Context para esta página, después creamos los controles necesarios para cada propiedad (Entry, Label, Button, Activity Indicator, etc) y establecemos el Binding correspondiente hacía cada una de las propiedades definidas en la clase ViewModel.

Ya tenemos todo el código necesario para ejecutar nuestra app, visualmente se ve de la siguiente manera:

Ahora ingresaremos los datos para que nuestra Azure Function pueda procesarlos y devolvernos un resultado, controlando todo desde nuestra app.

Como podemos observar nuestra aplicación funciona correctamente y podemos verificar los diferentes resultados que podemos obtener con base a la información enviada a nuestra Azure Function.

Conclusión
Tradicionalmente, las aplicaciones móviles estaban conectadas a servicios locales. La creación del nivel de servicio requería el conocimiento de la plataforma de servidor y un paradigma de programación. Los desarrolladores trabajaban en configurar los servidores de forma adecuada. A veces se dedicaban días o incluso semanas a la creación de una canalización de implementación confiable y segura, aunque esto se sigue haciendo.
Ahora sabemos que con Azure Functions podemos crear lógica de negocios sin necesidad de convertirnos en expertos en lo relacionado con el servidor, podemos crear un backend en cuestión de minutos y agilizar el desarrollo de nuestras apps móviles.

Link al Repositorio en GitHub
https://github.com/EbarriosCode/Xamarin-Azure-Functions

Referencias
https://docs.microsoft.com/en-us/azure/azure-functions/
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/data-cloud/azure-services/azure-functions?tabs=windows
https://cuidateplus.marca.com/alimentacion/diccionario/indice-masa-corporal-imc.html
https://www.efesalud.com/aprende-calcular-peso-saludable/

Xamarin Forms y Entity Framework Core SQLite, Persistencia y Acceso a Datos Locales en dispositivos móviles

Eduardo Barrios — Tue, 17 Dec 2019 07:02:20 +0000

Esta publicación forma parte del segundo calendario #AdvientoXamarin en español, una iniciativa liderada por Luis Beltrán.

A continuación les traigo un aporte sencillo pero no menos importante en el desarrollo de aplicaciones con Xamarin Forms, estoy seguro que en más de una ocasión hemos necesitado guardar información en una base de datos local dentro del dispositivo móvil y regularmente con el motor de Base de Datos SQLite tal cuál es el caso en esta implementación. A la hora de trabajar con datos para los desarrolladores .NET una opción muy familiar es Entity Framework debido a que puedes utilizarlo en diversas soluciones .NET tales como Proyectos de Consola, Windows Form, ASP.NET Web Forms, ASP.NET MVC, WebApis, WPF, UWP, etc. Obviamente a la lista anterior debes incluir aplicaciones móviles multiplataforma con Xamarin Forms.

EF Core
Entity Framework es un ORM (object-relational mapper) que permite a los desarrolladores trabajar con bases de datos utilizando objetos .NET.

Microsoft define Entity Framework (EF) Core como una versión ligera, extensible, de código abierto y multiplataforma de la popular tecnología de acceso a datos Entity Framework, EF Core soporta numerosos tipos de bases de datos tales como: SQLite, SqlServer, MySQL, Oracle, PostgreSQL, Firebird, etc.
En este post demostraremos lo fácil que es utilizar EF Core en aplicaciones de Xamarin Forms para acceder a una base de datos local SQLite en las plataformas Android y iOS.

Nota: Aunque esta implementación utiliza el patrón de arquitectura de software MVVM, la idea principal es demostrar el fácil acceso a datos y todo el provecho que le puedes sacar a EF Core, más aún si haz tenido experiencia con EF Core en otro tipo de soluciones .NET

Esta es una simple implementación que trata de como almacenar registros en una Base de Datos SQLite, utilizaré los modelos Albumes y Artistas que he utilizado en post anteriores, crearemos una vista que contenga un formulario para crear albumes y posteriormente una vista que contenga un elemento de lista para mostrar los albumes almacenados en la Base de Datos.

Empezaremos creando un nuevo proyecto de Xamarin Forms en Visual Studio 2019.

Teniendo nuestro proyecto creado la primero será agregar el paquete Nuget Microsoft.EntityFrameworkCore.Sqlite en el proyecto compartido de Xamarin Forms.

Ahora vamos a estructurar el código del proyecto compartido creando los siguientes directorios:

Nota: La página MainPage.xaml que se crea por defecto al crear el proyecto fue movida al directorio Views, el namespace también fué modificado de XamEFCore que hace referencia a la raíz en el proyecto compartido a XamEFCore.Views y de la misma manera en el codebehind MainPage.xaml.cs.

El siguiente paso es crear un clase que sirva como contexto de datos, si ya haz trabajado con otras soluciones .NET como MVC, WebApis, etc, seguramente esto te será muy familiar.
El contexto de datos es una clase en una solución .NET que hereda de la clase DbContext contenida en el namespace System.Data.Entity.DbContext y nos permite realizar las siguientes tareas:

Administrar la conexión de la base de datos
Configurar modelos y relación
Consultar base de datos
Guardar datos en la base de datos
Configurar el seguimiento de cambios
Almacenamiento en caché
Gestión de transacciones

Crearemos la clase contexto la llamaré AppDbContext y heredará de la clase DbContext, no olvidar agregar la referencia a Microsfot.EntityFrameworkCore.
Crearemos un atributo propio de la clase AppDbContext que nos servirá para setear la ruta y el nombre de la base datos para cada plataforma en este caso Android y iOS, este valor lo recibiremos mediante el método constructor de este contexto, seguidamente exponemos las propiedades DbSet que representan colecciones de las entidades especificadas en el contexto y sobreescribimos el método OnConfiguring para indicarle a EF Core que utilizaremos SQLite mediante el optionsBuilder pasandole como parámetro la ruta y el nombre de la base de datos que ya recuperamos y asignamos al atributo DbPath.

Nota: La ruta debe obtenerse en tiempo de ejecución.

En el siguiente paso vamos a recuperar la ruta en donde se almacenará la base datos específicamente para cada plataforma, debemos tomar en cuenta que el manejo de archivos y directorios es independiente para cada plataforma por lo que el almacenamiento de la base de datos se maneja de diferente manera tanto en Android como en iOS. Utilizaremos el Servicio de Dependencias (Dependency Service) de Xamarin Forms que nos permitirá implementar funcionalidades nativas para cada plataforma en este caso recuperar la ruta de almacenamiento de la base de datos, a grandes rasgos, Dependency Service consiste en crear una interface en el proyecto compartido e implementar esa interface en cada proyecto nativo con funcionalidades nativas para lograr comportamientos o funcionalidades propias de cada sistema operativo.
Sabiendo lo anterior procedemos y en el proyecto compartido de Xamarin Forms crearemos una interface en el directorio Interfaces y la llamaremos IConfigDataBase la cuál únicamente contendrá un método que retorna un string que hace referencia a la ruta de almacenamiento de la base de datos y recibe un parámetro tipo string que hace referencia al nombre de la base de datos, cada implementación de esta interface se encargará de encadenar o combinar la ruta y el nombre para devolver un único string.

Ahora vamos a implementar la interface anterior en el proyecto de Xamarin.Android, crearemos un directorio llamado Implementations que contendrá una clase llamada ConfigDataBase e implementamos el método GetFullPath especifícamente para Android.

Realizaremos nuevamente el paso anterior pero esta vez para el proyecto Xamarin.iOS.

En el siguiente paso vamos a obtener una instancia del contexto de datos cuando se inicia la aplicación, esto garantiza que cuando ésta se ejecute por primera vez, independientemente de la plataforma en la que corra en tiempo de ejecución obtendremos la ruta de almacenamiento de la base de datos y se la mandaremos al método constructor del contexto de datos, para ello iremos al codebehind de App.xaml, escribiremos un método Static que regresará una nueva instancia del contexto, utilizamos el Dependency Service para obtener la ruta de almacenamiento de cada plataforma, seguidamente utilizaremos ese método Static en el método constructor y crearemos la base de datos con la instrucción Database.EnsureCreated().

Crearemos una clase que nos sirva como Servicio para acceder y realizar operaciones a la base de datos mediante EF Core y Linq, en este ejemplo nos centraremos en Crear y Listar objetos tipo Album, la clase se llamará DBDataAccess y estará dentro del directorio Services.
Obtenemos el contexto creado en el inicio de la aplicación y lo utilizamos para el manejo de objetos.

El método Create devuelve un bool y su valor depende de, si el objeto se creó correctamente.

El método Get es un método genérico que devuelve una lista de objetos y recibe 3 parámetros: parámetro 1 una condición, parámetro 2 ordenar por algún atributo propio del modelo y parámetro 3 la relación con otro modelo en este caso Artista.

Realicé unas modificaciones para crear un ListView con dos opciones de menú crear y listar registros y se ve de la siguiente manera:

Nota: No entraré en detalles en cuanto al código de la Vista y el ViewModel asociado a la vista principal, puedes revisar el código en el repositorio de github.

Ahora crearemos en el directorio Views una Vista llamada AlbumPage aquí agregaremos un formulario para ingresar datos de Albumes y que estos se almacenen en la base de datos, previamente crearemos una clase llamada AlbumesViewModel en el directorio ViewModels, esto para poder agregar el BindingContext mediante código XAML en la vista.

En la clase AlbumesViewModel crearemos la propiedades a enlazar mediante Binding con la Vista.

Crearemos el Command que se ejecutará cuando presionemos el Button Guardar, y utilizaremos el DataService de Albumes e invocamos al método Create y le pasamos el nuevo objeto Album que construimos a partir de los datos ingresados en el formulario.

Nuestra View para crear Albumes se verá de la siguiente manera:

Llenamos el formulario.

Nota: El Picker de Artistas se carga mediante una lista de Artistas almacenada en la base de datos, utilicé un método temporal para crear dichos artistas en la tabla Artista, lo utilice únicamente para tener datos en dicha tabla, en otro escenario real esa lista podría venir de un WebApi o cualquier otra fuente de datos, no haré énfasis en esa funcionalidad, puedes revisar el código en el repositorio de github.

Al presionar el Button Guardar se ejecuta el Command y el resultado es el siguiente:

Ya es posible almacenar Albumes, el siguiente paso es mostrar un ListView con la lista de Albumes recuperada de la base de datos.

Crearemos una nueva View en el directorio Views y la llamaremos AlbumesPage.

Nota: Esta View utiliza el mismo ViewModel en su propiedad BindingContext.

Ahora crearemos un método para recuperar esa lista de Albumes almacenada en la tabla Albumes de la base de datos y lo invocaremos en el método constructor de AlbumesViewModel.

El resultado es el siguiente:

Guardamos más Albumes en la base de datos y podremos visualizar como el ListView crece.

Conclusión

Personalmente como desarrollador .NET encuentro muchas ventajas sobre el uso de Entity Framework Core para manipular datos y bases de datos, el rendimiento de EF Core ha mejorado exponencialmente con respecto a versiones anteriores, además manipular los datos como objetos y realizar consultas mediante Linq es genial y más si previo a utilizarlo con Xamarin Forms lo utilizas en otras soluciones .NET

Link al repositorio en GitHub:
https://github.com/EbarriosCode/Xamarin-y-Entity-Framework-Core-SQLite

Referencias:
https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/ef/overview
https://docs.microsoft.com/es-es/ef/ef6/fundamentals/working-with-dbcontext
https://www.entityframeworktutorial.net/efcore/entity-framework-core-dbcontext.aspx

Patrón Repositorio (Repository Pattern) y Unidad de Trabajo (Unit Of Work) en ASP.NET Core WebApi 3.0

Eduardo Barrios — Sat, 07 Dec 2019 18:19:56 +0000

Una aplicación de software típica naturalmente necesitará acceder a algún tipo de almacén de datos para llevar a cabo operaciones CRUD (Crear, Leer, Actualizar, Eliminar) en los datos, por lo general esto podría ser algún tipo de base de datos, sistema de archivos o cualquier tipo de mecanismo de almacenamiento utilizado para persistir de información.
En algunos casos guardar o crear datos puede requerir persistencia en archivos nuevos o crear una nueva fila en una tabla de una base de datos, en otros casos guardar datos nuevos puede requerir varias interacciones con varios servicios basados en la web o aplicaciones y otros servicios que no son generalmente gestionados por nosotros mismos.

Para ambos casos podemos hacer uso del patrón repositorio (Repository Pattern) y una unidad de trabajo (Unit Of Work), pero, ¿qué es el patrón repositorio?
El patrón repositorio consiste en separar la lógica que recupera los datos y los asigna a un modelo de entidad de la lógica de negocios que actúa sobre el modelo, esto permite que la lógica de negocios sea independiente del tipo de dato que comprende la capa de origen de datos, en pocas palabras un repositorio media entre el dominio y las capas de mapeo de datos, actuando como una colección de objetos de dominio en memoria (M. Fowler), ahora bien, ¿qué es el patrón unidad de trabajo?
Este centraliza las conexiones a la base de datos realizando un seguimiento de todo lo que sucede durante una transacción cuando se usan capas de datos y revertirá la transacción si Commit() no se ha invocado o existen incongruencias lógicas.

Para este ejemplo utilizaremos un repositorio genérico y una unidad de trabajo aplicándolo al proyecto de Albumes y Artistas que contiene una base de datos en memoria de sql server. Este proyecto lo he utilizado en post anteriores, he realizado algunas adaptaciones al código del repositorio que me parecen geniales agregando programación asíncrona, separando servicios, desacoplando componentes para lograr una mejor infraestructura dentro del proyecto y que puedan utilizarla en sus proyectos.

Vamos a crear un proyecto con una solución en blanco en Visual Studio 2019 Preview, luego crearemos 3 carpetas de soluciones y dentro cada carpeta agregaremos un proyecto que hace referencia a las capas WebApi que contendrá el manejo de Controllers para exponer o almacenar datos, Entities que hace refencia a los modelos, en un escenario mas sencillo los modelos los crearíamos en el proyecto WebApi pero recuerda que buscamos desacoplar componentes, la tercer capa llamada DataAccess que se encargará de acceder a la información de la base de datos mediante un repositorio genérico y afectar la base de datos mediante una unidad de trabajo. Los proyectos Entities y DataAccess son bibliotecas de clases .NET Standard. La organización del proyecto quedaría de la siguiente manera:

En el proyecto DataAccess crearemos las Clases que implementan las Interfaces del repositorio genérico y la unidad de trabajo, seguidamente haremos uso de inyección de dependencias de ambos, si no sabes que es inyección de dependencias revisa mi post anterior acerca de Inyección de dependencias en. NET Core.

Creamos la unidad de trabajo, su respectiva Interface y Clase.
UnitOfWork utiliza el contexto de datos que pertenece a la capa de Entities, no olvidar hacer referencia a dicho proyecto.

Luego crearemos el repositorio genérico.
Puedes notar que tradicionalmente se inyecta una propiedad de contexto de datos en el constructor del repositorio pero para esta implementación inyectamos una propiedad de tipo IUnitOfWork, esto para lograr centralizar las operaciones a la base de datos.

Nos centraremos en las opciones leer y crear, sobrecargamos el método GetAsync para poder agregar una condición, ordenar por algún atributo propio del modelo y agregar relaciones con otros modelos mediante alguna propiedad de navegación.

Ahora vamos a agregar la dependencia en el contenedor de control de inversión IoC, está clase se crea en una carpeta llamada Middleware, este nombre es arbitrario y debe estar situada en el proyecto WebApi.

Seguidamente utilizamos el contenedor de inversión de control para inyectar el servicio en la clase Startup método ConfigureServices en el proyecto WebApi.

Ahora vamos a utilizar el repositorio genérico y la unidad de trabajo en nuestro Controller, debemos inyectar la interface IGenericRepository pero debemos darle un tipo y en este caso debe ser tipo Album, inyectamos la interface de unidad de trabajo IUnitOfWork, después asignamos la inicialización que el IoC se encargo de instanciar en el inicio y seguidamente podemos proceder a utilizar alguno de los métodos del repositorio, en este caso el método GetAsync del repositorio en el método Api Get, nótese que estamos pasando 3 parámetros: parámetro 1 una condición, parámetro 2 ordenar por algún atributo propio del modelo y parámetro 3 la relación con otro modelo en este caso Artista. Para el caso del método Api Create utilizamos el método del repositorio CreateAsync el cuál recibe un modelo serializado en formato json a través del verbo HTTP Post.

Finalmente vamos a probar el funcionamiento de este proyecto, nos apoyaremos de PostMan para realizar las peticiones HTTP hacía nuestros métodos Api.

Tras compilar, ejecutar y hacer una llamada HTTP Get al método api Get del WebApi obtenemos el listado de Albumes relacionados con el modelo Artista.

Comprobamos el funcionamiento del método api Create enviando un objeto json con la propiedades de Album y no olvidar cambiar el tipo de petición a HTTP Post en PostMan.

El nuevo objeto se creó correctamente, ahora volveremos a realizar la petición al método Get para comprobar la existencia del nuevo registro en la lista de Albumes.

Como podemos observar está implementación funciona correctamente, hemos utilizado el patrón repositorio y una unidad de trabajo.
Entre los beneficios de utilizar el patrón repositorio podemos mencionar centralización de la lógica de acceso a datos, punto de sustitución para las pruebas unitarias y arquitectura flexible que se puede adaptar a medida que evoluciona el diseño general de la aplicación.
En cuanto al patrón unidad de trabajo personalmente uso la unidad de trabajo para reducir mucha inyección de dependencia, puedo tener una unidad de trabajo de la base de datos y una vez que use la inyección de dependencias para inyectar el contexto de la Base de datos en esa unidad de trabajo, no necesito inyectar cada repositorio de modelos donde quiero usarlos, pero solo accederé a los repositorios desde el unidad de trabajo, esto también me ayuda a crear instancias de un repositorio solo cuando lo necesito en un método específico.

Conclusión

El patrón repositorio está destinado a crear una capa de abstracción entre la capa de acceso a datos y la capa empresarial para que pueda ayudar a aislar la aplicación de los cambios en el almacén de datos y facilitar las pruebas unitarias automatizadas para el desarrollo basado en pruebas.

En esta implementación hacemos uso de Entity Framework Core en una implementación de la Unidad de Trabajo y Patrón Repositorio.
Por lo tanto, no es del todo necesario en estos días envolver Entity Framework Core en un patrón de Unidad de Trabajo, porque básicamente se está envolviendo una abstracción sobre una abstracción, pero para fines de entender como funciona Unidad de trabajo hacemos uso de Entity Framework Core.
Además únicamente tenemos un repositorio y el objetivo de la unidad de trabajo es centralizar y unificar repositorios.

Link al repositorio en Github:
https://github.com/EbarriosCode/RepositoryUnitOfWorkNetCore3

Referencias:
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-implemenation-entity-framework-core
https://martinfowler.com/eaaCatalog/repository.html
https://www.martinfowler.com/eaaCatalog/unitOfWork.html

Inyección de Dependencias(DI) en ASP.NET Core, mejores prácticas para escribir código reutilizable, escalable y desacoplado

Eduardo Barrios — Sat, 16 Nov 2019 04:24:07 +0000

Los Desarrolladores de Software siempre estamos en busca de una forma reutilizable para resolver un problema común y para lograrlo es necesario recurrir a estándares como lo son los patrones de diseño de Software. Antonio Leiva define un patrón de diseño como una forma de solucionar un problema que se puede extraer, explicar y reutilizar en múltiples ámbitos.

Ahora sabemos que es un patrón de diseño, pero!!!

Inyección de Dependencias es un patrón de diseño de software que nos permite desarrollar componentes acoplados libremente o desacoplados para obtener como resultado la fácil gestión de cambios a futuro, implementación fácil de pruebas unitarias, factoría para emitir instancias de clases, prevención de fugas de memoria, entre otros.
DI proporciona un mecanismo para la construcción de gráficos de dependencia independientes de las definiciones de clase, aplicando esta técnica nuestras clases van a depender de interfaces y no de implementaciones, esto se relaciona directamente con el primero de los 5 principios para desarrollar software de calidad, haciendo referencia a SOLID y el principio de responsabilidad única.

Por su parte ASP.NET Core nos permite la utilización del patrón de diseño Inyección de Dependencias sin la necesidad de utilizar librerías de terceros para lograrlo, además ASP.NET Core provee un Contenedor de Inversión de Controles(IoC) quien es el encargado de proveer las instancias de los tipos los cuales le decimos en el inicio de la Aplicación(Startup).

Para este post utilizaremos un proyecto WebApi de .NET Core 3.0, utilizaré los mismos modelos, base de datos en memoria y estructura del proyecto de mi post anterior.

Base de Datos en memoria con ASP.NET Core 3.0 MVC + Entity Framework Core

Eduardo Barrios ・ Nov 7 '19

#csharp #dotnet #database

Vamos a Visual Studio Comunity 2019.
Inicialmente visualizamos el archivo HomeController.cs, este código utiliza un servicio para mostrar un listado de Albumes y su relación con Artista, mediante Entity Framework Core. Por el momento no estamos pensando en inyección de dependencias.

El servicio utiliza el Contexto de Datos para traer el listado de la Base de Datos.

La clase contexto WebApiDbContext posee una sobreescritura del método OnConfiguring para enviarle la configuración de la base de datos en memoria y el método constructor está sobrecargado.

El resultado es el siguiente

Analizemos el código anterior, como punto principal vemos que funciona, pero nuestro controlador crea y depende directamente de la instancia de la clase AlbumesService, las dependencias de código son problemáticas y deben evitarse, ¿por qué? supongamos que queremos reemplazar la implementación de AlbumesService, debería modificar el controlador también y esto en un proyecto grande representa problemas porque puede que olvide modificar diferentes controladores que utilicen el mismo servicio y el funcionamiento del sistema seria inconsistente. Un problema más en este código podría ser que si AlbumesService tuviera alguna dependencia esta debe ser configurada en el controlador o clase que utilice el servicio de Albumes. Por otra parte esta implementación como se encuentra en este momento dificultaría la realización de pruebas unitarias debido a que sería difícil probar componentes que no están desacoplados y no hay manera de pasarle un servicio fake porque se está utilizando el servicio de forma explicita como una instancia directa.

Ahora abordemos la problemática y solucionemos mediante Inyección de Depedencias.

Pensemos en Inyección de Dependencias, como primer paso debemos utilizar una interface que nos permita abstraer la implementación de dependencias, vamos a relacionarla con el servicio Albumes.

El siguiente paso es decirle al servicio de Albumes que implemente la interface IAlbumesService.

Ahora debemos registrar el servicio en el Contenedor de servicios integrados IServiceProvider que nos proporciona ASP.NET Core, los servicios son registrados en el método ConfigureServices de la clase Startup de la aplicación, una vez definido el servicio debemos registrarlo.

Observemos que para este escenario estamos utilizado el método AddTransient para indicar la interface para el servicio y su implementación, esto hace referencia al ciclo de vida de los servicios que viven en el contenedor. Dentro del contenedor que nos proveé ASP.NET Core existen 3 ciclos de vida básicos los cuales podemos utilizar para inicializar las dependencias desde nuestro contenedor.

Transient: Se crean cada vez que se solicitan desde el contenedor de servicios. Esta vida útil funciona mejor para servicios ligeros y sin estado.
Scoped: Se crean una vez por solicitud del cliente(conexión). Se utiliza cuando queremos servir la misma instancia dentro del mismo contexto de una petición HTTP, pero diferente entre distintos contextos HTTP.
Singleton: Se crean la primera vez que se solicitan o cuando Startup.ConfigureServices se ejecuta y se especifica una instancia con el registro del servicio. Cada solicitud posterior utiliza la misma instancia.

Para el paso anterior hay otra alternativa por la que podemos optar, personalmente me gusta la siguiente alternativa que nos recomienda Microsoft, consiste en separar todos los servicios en una clase static dentro de un método que recibe como parámetro el IServiceCollection y lo retorna con los servicios ya registrados y unificados para después inyectar todo en el método ConfigureServices, creamos una carpeta llamada Middleware este nombre es arbitrario y dentro una clase llamada IoC que hace referencia al Contenedor de Inversión de Control.

Ahora invocamos el método AddDependency en el método ConfigureServices en la clase Startup.cs

Seguidamente vamos al controlador a cambiar esa instancia explicita que teniamos con AlbumesService y la modificaremos pensando en inyectar dependencias, observemos que ahora en lugar de instanciar AlbumesService tenemos una propiedad de lectura que además es una interface IAlbumesService y en ningún momento la inicializamos nosotros, inyectamos la dependencia en el método constructor y quien se encarga de instanciar el servicio es el contenedor, he aquí la razón de agregar las dependencias en el método ConfigureServices de la clase Startup.

Ahora compilamos, ejecutamos y vamos a la ruta de nuestro WebApi desde Postman y podemos observar que este código funciona, el resultado es el mismo cierto, pero en el estado actual en el que se encuentra nuestro código es mejor, debido a que abordamos las problemáticas anteriormente mencionadas.

En conclusión la técnica de Inyección de Dependencias nos ayuda a escribir código reutilizable debido a que el servicio no se instancia en ningún controlador ni en otra clase que lo utiliza podemos reutilizarlo en N cantidad de controladores y clases que necesitemos, ya que la lógica está encapsulada dentro de un servicio, además es escalable y mantenible, podemos modificar la lógica del servicio sin afectar otras partes de nuestro sistema y evitar inconsistencias lógicas, además el código está desacoplado por lo que fácilmente podemos comprobar el correcto funcionamiento de un fragmento de código en específico.

Link al repositorio en GitHub:
https://github.com/EbarriosCode/DependencyInjectionDotNetCore3.0

Referencias:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-3.0
https://devexperto.com/patrones-de-diseno-software/

Base de Datos en memoria con ASP.NET Core 3.0 MVC + Entity Framework Core

Eduardo Barrios — Thu, 07 Nov 2019 16:13:22 +0000

Utilizar una base de datos en memoria es muy útil cuando necesitamos probar componentes utilizando un escenario muy parecido al que nos provee una conexión a una base de datos real, obviamente esto sin el consumo de recursos y la sobrecarga de las operaciones reales a la base de datos, también es útil cuando no se tiene acceso a la base de datos real que posiblemente se encuentre en un servidor al que no tenemos acceso.

Cabe mencionar que las bases de datos en memoria están diseñadas para ser una base de datos de propósito general únicamente para pruebas, por lo que no deberíamos tratar de imitar a una base de datos relacional ni tratar de llevar este tipo de técnica a un ambiente productivo.

Sabiendo lo anterior empezamos creando el proyecto en Visual Studio 2019.

Una vez creado el proyecto de ASP.NET Core 3.0 MVC

El siguiente paso es crear los modelos que necesitaremos para logar persistencia de información en la base de datos en memoria.

Para este ejemplo utilizaremos la relación de modelos Álbum y Género donde un Álbum puede contener un Artista y un Artista puede pertenecer a múltiples Álbumes, vamos a utilizar el enfoque Code First este es el enfoque que nos conviene en este escenario.

Después de la creación de los modelos y enfocarnos en el código primero vamos a instalar el nuget de Entity Framework Core InMemory para después crear el Contexto de Datos y decirle a Entity Framework Core que proceda a mapear nuestros modelos.

Ahora creamos el Contexto, creamos una carpeta llamada DataContext y dentro de esta creamos una nueva clase llamada AppDbContext la cuál hereda de la clase DbContext que está definida dentro del nuget de Entity Framework Core claro sin olvidar agregar la referencia a Microsoft.EntityFrameworkCore.

El siguiente paso es dar de alta el servicio en el método ConfigureServices de la clase Startup.cs aquí debemos decirle al servicio que utilize el contexto que acabamos de crear y decirle que la base de datos será en memoria.

Luego debemos crear una clase static y un método static void para inicializar la base de datos. Debido a que no podemos hacerlo por medio de sql y el enfoque para este escenario es code first debemos apoyarnos de Entity Framework Core para persistir de datos para que cuando se cree la base datos en memoria seguidamente empiece el proceso de inicializar y poblar de información las tablas de la base de datos.
Situados dentro de la carpeta DataContext crearemos una nueva carpeta llamada Data y dentro de Data vamos a crear una nueva clase llamada DbInitializer no olvidar definirla como static y seguidamente crear el método public static void Initialize(IServiceProvider serviceProvider) el parámetro que recibe este método es una interfaz que utilizaremos para inyectar la dependencia y abstraer la implementación para utilizar el contexto de datos, aprovecharemos que ASP.NET Core admite el patrón de diseño de software de inyección de dependencias, técnica para lograr la Inversión de Control (IoC) entre las clases y sus dependencias.

Seguidamente vamos a modificar el código del método Main en la clase Program.cs necesitamos obtener el IWebhost que alojará la aplicación, lo asignamos a un objeto anónimo, luego necesitamos acceder a un servicio con alcance en el inicio (Startup) para ejecutar tareas de inicialización y por último debemos crear la instancia del contexto en la capa de servicios e invocar al método DbInitializer.Initialize(services) enviando como parámetro el servicio de inicialización.

Ya estamos cerca del final, tenemos la configuración lista para acceder a los datos de una base de datos en memoria, vamos al HomeController y utilizaremos el contexto de datos para listar los datos y mostrarlos en la vista Index.

Creamos una propiedad de lectura de tipo AppDbContext, inyectamos la dependencia en el constructor del HomeController y recuperamos la lista de Álbumes y su relación con el modelo Artista asignando el resultado a un objeto anónimo que le pasaremos a la vista.

Tipamos nuestra vista Index para que reciba una lista de Álbumes y luego agregaremos este código para mostrar en una tabla de html las propiedades de nuestra lista de Álbumes.

Al compilar y ejecutar nuestra aplicación web el resultado es el siguiente.

Link al repositorio en GitHub
https://github.com/EbarriosCode/Base-de-Datos-en-Memoria-Net-Core-3.0-MVC-EFCore