tutorial - Controladores de API web ASP.NET sin System.Web.Http(conectable, arquitectura desacoplada)

web api rest c#

Question

Estoy creando un marco de proyecto conectable usando ASP.NET Web API. Tengo muchas agallas resueltas, pero estoy teniendo un problema con una parte de la arquitectura que no estoy completamente seguro de cómo desacoplar.

Como un ejemplo simplificado, tengo lo siguiente:

• Servicio / Capa de presentación (proyecto alojado en la API web simple, muy poco dentro de esto, y básicamente es solo un shell que maneja el alojamiento en IIS o autohospedado)
• Capa de dominio, con el núcleo, piezas de dominio del proyecto
• Servicios (N número de servicios, cada uno con una referencia a la capa de dominio: think microservices). Actualmente, cada uno de estos Servicios también tiene una referencia a ASP.NET Web API 2.1

Ahora, todos los Servicios hacen referencia a la capa de Dominio porque tiene interfaces, ayudantes, etc. Pero, la capa de Dominio también hace referencia a cosas como ASP.NET Web API 2.1 y más. Mi idea era tener un "BaseController" base en el dominio del que pudieran heredar los controladores de cada uno de los servicios, y que a su vez heredaría necesariamente los elementos conectados como Get (), Post (), etc. El problema es que no quiero que cada uno de estos servicios también tenga que hacer referencia a ASP.NET Web API 2.1 y a las demás dependencias. Quiero que puedan usarlos a través de abstracciones sin hacer referencia a ellos directamente. En otras palabras, quiero un acoplamiento más flexible y quiero que los Servicios puedan vivir de forma autónoma e independiente de System.Web.Http. Me ayudaría a hacer cumplir las pruebas unitarias y los principios SÓLIDOS a medida que el proyecto crezca.

Tal vez estoy tomando el enfoque equivocado aquí, pero tal vez no. Mi objetivo principal es crear un marco de microservicios enchufable utilizando ASP.NET Web API con cada microservicio viviendo como un ensamblaje independiente. Entonces, si hay otro enfoque recomendado, soy todo oídos.

Espero que esto tenga sentido. ¿Alguna sugerencia? Por lo que vale, estoy bastante familiarizado con los conceptos de patrones de diseño y principios SÓLIDOS; simplemente no estoy seguro de cómo encadenar todo esto mientras mantengo parte del manejo automático de solicitudes que los controladores proporcionan de forma nativa.

¡Gracias!

Answer 1

Tu intención es genial, la implementación no tanto. Lo que en realidad se llama Servicios de Aplicación, esos son los servicios que implementan los casos de uso de la aplicación usando el Dominio. Cuando dice que no quiere estar conectado a System.Web.Http, etc., creo que quiere decir que no desea que su aplicación (especialmente el Dominio) se una a la estructura de WebApi.

Creo que has entendido mal lo que significa el desacoplamiento. No se trata realmente de un ensamblaje que no dependa de otro, se trata de no acoplar sus objetos / capa a un detalle de implementación de otros objetos / capas. Es por eso que el dominio nunca debe saber sobre los controladores, WebApi, Mvc, etc. no son parte del dominio, son parte de la interfaz de usuario o API pública.

Solo la capa API (una coincidencia de nombre) debe saber sobre los controladores y cualquier marco que esté usando (incidentalmente WebApi), cualquier otra cosa solo sabe sobre sus preocupaciones. Entonces la API (usos) -> Capa de aplicación -> Dominio.

Tener componentes autónomos está bien, pero realmente no quieres que un solo ensamblaje maneje todo. Mantenga las cosas limpias y tenga algo así como:

• MyFeature.ApplicationServices
• MyFeature.Domain
• MyFeature.Persistence
• incluso MyFeature.UIWidgets (Web / Wpf, etc.)

Esto es solo una sugerencia, lo importante es mantener las preocupaciones separadas.

Aquí hay un poco de código

public class MyAppService
{
public void DoSmth(InputData data){}
}
public class MyApiController
{
public MyApiController(MyAppService svc) { }
public void Post(SomeModel model)
{
var svcInput=model.ToServiceInput();
_svc.DoSmth(svcInput);
}
}

Su servicio de aplicación obtiene un modelo de entrada del controlador y lo usa para hacer su trabajo. El Servicio nunca sabe sobre webApi ni nada, solo sobre el modelo de entrada. Y las cosas están desacopladas y son fáciles de probar.