Как создать промежуточное ПО с конечными точками API в .NET Core

Вместо отдельного промежуточного программного обеспечения вы можете настроить промежуточное программное обеспечение MVC для обнаружения контроллеров из другой сборки:

// using System.Reflection;

public void ConfigureServices(IServiceCollection services)
{
    ...
    services
      .AddMvc()
      .AddApplicationPart(typeof(TodoController).GetTypeInfo().Assembly);

Контроллеры являются частью промежуточного программного обеспечения MVC, они не являются отдельной частью конвейера запросов (но это и есть промежуточное программное обеспечение). Когда вы регистрируете пользовательское промежуточное ПО, оно по умолчанию вызывается при каждом запросе, и у вас есть HttpContext context в качестве входного параметра для работы с/редактирования данных запроса/ответа. Но ASP.NET Core предоставляет расширения Map*, которые используются как соглашение для разветвления трубопровода.

Карта разветвляет конвейер запросов на основе совпадений заданного пути запроса. Если путь запроса начинается с заданного пути, ветвь выполняется.

Пример:

private static void HandleMapTodo(IApplicationBuilder app)
{
    app.Run(async context =>
    {
        await context.Response.WriteAsync("/api/todo was handled");
    });
}

public void Configure(IApplicationBuilder app)
{
    app.Map("/api/todo", HandleMapTodo);
}

Обратите внимание, что поскольку промежуточное ПО ничего не знает о промежуточном ПО MVC, у вас есть доступ только к «сырым» запросам и нет таких функций, как привязка модели или фильтры действий MVC.

Поскольку это похоже на идеальный подход к микросервисам (похожий на то, что моя команда делает прямо сейчас), я бы создал клиентскую сборку, которая может использовать ваш API, тот, который содержит ваш TodoController, если вы определяете контракт и интерфейс, для этого API, вы можете зарегистрировать его в другой своей сборке, поскольку это промежуточное ПО, а также вы можете имитировать это поведение в своих модульных тестах.

Итак, как я уже сказал, вы можете внедрить свой клиент в метод ConfigureServices, вы можете создать:

public static IServiceCollection AddTodoRestClient(this IServiceCollection services)
{
    services.AddSingleton<ITodoRestClient, TodoRestClient>();
    return services;
}

Также учтите, что вам нужно будет указать enpoint, поэтому это может выглядеть так:

public static IServiceCollection AddConfiguredTodoClient(this IServiceCollection services, string todoEndpoint)
{
    AddTodoClient(services);
    ITodoRestClient todoRestClient = services.BuildServiceProvider().GetService<ITodoRestClient>();
    // Imagine you have a configure method...
    todoRestClient.Configure(services, todoEndpoint);
    return services;
}

Вы можете создать эти методы в классе TodoRestClientInjector и использовать их в методе Configure при запуске.

Я надеюсь, что это помогает

--- ПОДРОБНЕЕ, ЧТОБЫ ОТВЕЧАТЬ НА КОММЕНТАРИИ ---

Для меня TodoClient — это клиентская библиотека Rest, которая реализует вызовы ToDo API (я отредактировал предыдущий код, чтобы он был TodoRestClient), такие методы, как, например, CreateTodoItem(TodoDto todoItem), реализация которого будет вызывать TodoController.Post([FromBody] item) или GetTodos(), который вызовет TodoController.Get() и т.д. и т.п....

Что касается точек... Этот подход подразумевает наличие (по крайней мере) двух разных приложений (приложений .NET Core), с одной стороны, приложения ASP NET Core, в котором есть ваш TodoController, а с другой стороны, консольное приложение или другое приложение ASP NET. Core API, в каком классе запуска вы будете выполнять настройку клиента Rest (клиент Todo Rest)...

В подходе микросервисов с использованием docker в среде разработки вы будете использовать docker-compose-yml, но в традиционном подходе вы будете использовать конкретные порты для определения конечных точек...

Итак, представьте, что во второй службе у вас есть контроллер, которому нужно использовать TodoController, для достижения которого я буду использовать описанный выше подход, и «SecondController» будет выглядеть так:

  public class SecondController : Controller
    {
        private readonly SecondContext _context;
        private readonly TodoRestClient _todoRestClient;

        public TodoController(SecondContext context, ITodoRestClient todoRestClient)
        {
            _context = context;
            _todoRestClient= todoRestClient;
        }       

// Whatever logic in this second controller... but the usage would be like:

_todoRestClient.GetTodos()

}

Несколько заключительных советов: важно свести к минимуму вызовы между службами, потому что это увеличивает задержку, и все больше и больше, если это происходит в каскаде. Также рассмотрите использование Docker, выглядит сложно, но его довольно легко запустить, и, действительно, считается, что он используется в сценариях, которые вы представили, и в решениях, подобных моему.

Опять же, я надеюсь, что это поможет.

Хуан