Creando un Microservicio con C#, .NET Core y MongoDB

Sin olvidar los patrones, la arquitectura y los tests

Patricio Ferraggi
DotTech
5 min readSep 2, 2020

--

Picture from Alina Grubnyak on unsplash.com

¡Hola chicos! ¿Cómo han estado? En las últimas semanas, he estado en proceso de entrevistas para puestos de desarrollador de C#.

Trabajo con ASP.NET Core todos los días, lo que significa que cuando estoy en casa no elijo C# como lenguaje de practicas. Por esto mismo, el código C# que tengo en mi Github es bastante antiguo y pertenece a los primeros años de mi carrera.

Así que decidí usar los desafíos de programación que me brindan los empleadores para crear un código C# más nuevo para mi GitHub y, al mismo tiempo, crear una buena guía para que puedan seguir mejorando su desarrollo personal.

Qué esperar de este tutorial

Al final de la serie, tendremos un microservicio con las siguientes características:

  • Integrado con MongoDB.
  • Arquitectura en capas con una clara separación de responsabilidades.
  • Documentación de la API.
  • Soporte de Docker.
  • Tests Unitarios.

Introducción

Tenemos una pequeña empresa, vendemos 💻. Cada vez que se vende una computadora nueva debemos registrar el pedido con la cuantía y el cliente que lo compró.

Vamos a crear un pequeño microservicio que se conecta a una instancia de MongoDB y nos permite crear/leer/actualizar/eliminar pedidos, además de obtener algunos cálculos adicionales sobre el gasto de los usuarios.

Nuestro modelo de Order o Pedido será el siguiente:

Modelo de Order

Definición básica

Comenzamos creando una aplicación web ASP.NET Core 3.1 con la plantilla de API y la compatibilidad con Docker habilitada en Visual Studio 2019.

Plantilla para una aplicación ASP.NET Core 3.1

En nuestro caso, introducimos WeatherForecast, lo que nos creará un modelo y un controlador (Controller) con una API lista para ser usada.

WeatherForecast

Después de eliminar el código predeterminado, comenzamos creando nuestro modelo y un controlador básico llamadoOrdersController. Los primeros métodos que desarrollamos son POST y GET,lo que nos permite probar la creación y obtención de pedidos:

OrdersController con los métodos GET y POST

En el código anterior hemos realizado las siguientes tareas:

  1. Agregado los endpoints GetAll, Get y Post.
  2. Incluimos comentarios para la API pública.
  3. Versionado nuestra API usando la nomenclatura v1/[controller] en los endpoints.

Si están prestando atención, habrán notado que el Post tiene un modelo que aún no hemos definido: OrderCreateUpdate.

Cuando creas elementos en una base de datos, no se debe proporcionar un OrderId, ya que el pedido aún no existe, entonces es una buena práctica separar el modelo de API en dos para que estos puedan cambiar de forma independiente.

Este es el modelo para OrderCreateUpdate:

Modelo de OrderCreateUpdate

Conexión a la base de datos

Por ahora, en lugar de crear una base de datos local o jugar con Docker desde el comienzo, usaremos una base de datos en línea como las proporcionadas por MongoDBAtlas.

De vuelta en el proyecto, necesitamos encontrar una manera de configurar los ajustes para conectarnos a nuestra base de datos, lo hacemos usando el patrón de opciones que trae ASP.NET Core. Definimos la siguiente configuración:

Configuración de la BD: OrdersServiceOptions

Ahora que tenemos nuestra configuración lista, podemos pasar a crear nuestro primer repositorio que tendrá la responsabilidad de conectarse a nuestra instancia de MongoDB.

Este es el código de nuestro OrdersRepository:

Clase OrdersRepository

Como pueden ver, el repositorio crea la conexión con MongoDB mediante las opciones de configuración que definimos anteriormente. Además, se envía por parámetros unlogger, que se usará más tarde. A continuación, crearemos los métodos que se utilizan para obtener y crear Pedidos:

Métodos para obtener y crear pedidos de la clase OrdersRepository

Los tres métodos son muy simples:

  1. Obtenemos un solo pedido por id.
  2. Obtenemos todos los pedidos.
  3. Creamos un nuevo pedido (con el logging adecuado si falla la creación.)

Después de agregar estos métodos, creamos una interfaz de este repositorio para que podamos comenzar a usar la inyección de dependencias que proporciona .NET Core.

Interfaz de la clase OrdersRepository

Conectando las piezas

Volvemos a nuestra clase Controller para realizar las llamadas adecuadas a nuestro Repository.

OrdersController con llamadas a OrdersRepository

Agregamos la dependencia del repository (IOrdersRepository) en el constructor y lo usamos desde los endpoints. También manejamos diferentes respuestas dependiendo del resultado del repositorio y definimos explícitamente las posibles respuestas usando el tipo de respuestas producidas:ProducesResponseType.

El resultado de hoy

El resultado de lo desarrollado en este artículo es el siguiente:

1. POST

2. GET ALL

3. GET

Si tienen algo de experiencia en la construcción de API modernas, probablemente esten en shock. ¿Este tipo realmente va a usar el mismo modelo para la API y la base de datos? ¿Se va a llamar al repositorio desde el controlador? ¿Por qué todo está en el mismo proyecto?

No se preocupen, nos encargaremos de todo antes de que termine esta serie, les prometo que va a ser algo que valga la pena poner en su Github 😉.

Conclusión

Eso fue mucho, lo sé, tampoco entré en detalles de todos los patrones de aplicación usados ​​ya que hubiera sido imposible, pero en cada patrón usado hay un enlace a la guía oficial sobre cómo implementarlo en ASP.NET Core, los tutoriales de Microsoft son muy buenos y les darán los detalles que faltan.

Espero que les haya gustado esta primera parte, en siguientes entregas de esta serie se realizarán las tareas de actualizar y eliminar, se agregará el endpoint de información combinada y si hay tiempo también comenzaremos a separar mejor las responsabilidades y puliremos nuestro servicio.

Como siempre, si te gustó o no, házmelo saber en los comentarios y compártelo en las redes sociales 😀

Originally published at https://www.patferraggi.dev.

--

--

Patricio Ferraggi
DotTech

Soy un developer autodidacta Argentino que actualmente vive y trabaja en Bélgica. Intento mejorar diariamente mientras ayudo a otros a hacer lo mismo.