Arquitectura software versatil, clean code y asequible a unit test o TDD

Es fácil entender lo que se busca cuando perseguimos tener el código bajo cobertura de unit test, así como es fácil entender porque aplicar el diseño dirigido por test (TDD – Test Driven design) es tan conveniente y sus ventajas. Sin embargo tratar de trasladar todo eso a la práctica en ocasiones no es tan fácil como se pinta.

En esta entrada doy algunos consejos sobre una arquitectura software versátil para afrontar estos y otros problemas. 

Leer más…

Crea una API básica desde un proyecto vacío

Cuando creas un nuevo proyecto, ya sea de tipo WebApi o MVC, seguramente suelas utilizar plantillas. En muchos casos incorporan capacidad por encima de las necesarias, o condicionan tu desarrollo. No obstante es un muy buen punto de partida que se puede ajustar a tus necesidades. Suelen incluir unos controladores básicos, algunas vistas, les puedes incluir un mecanismo de autenticación y en ese caso te incluirán incluso modelo.

Sin embargo con las nuevas arquitecturas basadas en microservicios, es posible que no necesites nada de todo esto, y con unos simples servicios expuestos te sea más que suficiente para consumir la Api de un mircoservicio desde una aplicación SPA. Si este es el caso, en esta entrada te voy a mostrar como crear un proyecto de Api nuevo, sin utilizar ningún template, y haciendo uso de la clase StartUp en lugar de global.asax, como ya hacen muchos template, especialmente basados en .Net Core.

Leer más…

Cómo crear dinámicamente un contexto de Entity Framework Core en tiempo de ejecución

A medida que me introduzco más en arquitecturas de microservicios, trato de explotar sus diferentes ventajas. Una de ellas es poder usar una tecnología diferente para cada microservicio, por lo que es la oportunidad perfecta para explorar dotNet Core.

Ya he creado una entrada previa centrada en Core, para validar un token generado desde un servicio creado con .Net Framework. Ahora presento esta otra entrada donde he vuelto a aprovechar la arquitectura de Unit of Work, Repository Pattern y Entity Framework Code First de la que hablo en una de mis primeras publicaciones, en esta ocasión se trata de usarla con Entity Framework Core y además reforzarla con la creación de contextos de datos de forma dinámica en tiempo de ejecución y manteniéndola desacoplada de las demás capas, de forma que Entity Framework sea algo particular de la capa de datos.

Leer más…

Flow expectation test como parte de tus unit test.

En mi entrada sobre porque usar la librería Rhino Mock para unit test explico brevemente su utilidad para testear el “qué” hace un método o tu SUT (Sistem under test). A este “probar el qué” hace una función, sin entrar a los detalles técnicos sobre como cumple con su función se le puede conocer como test de flujo esperado o flow expectation test. En esta entrada te hablo sobre sus ventajas y su importancia.

Leer más…

Cómo usar azure functions para limpiar datos de una base de datos SQL.

Es común en aplicaciones empresariales encontrarse con ciertos procesos batch, que corren en segundo plano, para aplicar mantenimiento sobre el sistema de almacenamiento, integraciones de nuevos datos de referencia entre diferentes sistemas, actualización de estados, envío de mails de recordatorio, limpieza de datos…

En esta entrada voy a presentar como crear una función programada en el tiempo de forma regular, que elimine datos de nuestra base de datos como tarea de limpieza, usando únicamente Azure Functions para ello.

Leer más…

Unit of Work, Repository y Entity Framework Code First

En esta entrada voy a hablar un poco sobre una arquitectura para la capa de datos que a mi me esta funcionando muy bien. Se trata de aplicar el patrón Unit Of Work junto al Repository Pattern y Entity Framework Code First para crear una capa de acceso a datos totalmente desacoplada de la capa de negocio, de forma que nuestro modelo de aplicación y las capas superiores no se vean afectadas por un cambio en la tecnología utilizada para acceso a datos.

Leer más…