Сергей Соловьев

Когда-то решал уже похожую проблему. Только чтение батчей из кафки и сохранение в БД. Не знаю какой у тебя стек, но я решил так.

Создаю Channel и BackgroundWorker, который из этой очереди читает. В эту очередь кладутся объекты по типу InsertContext. В ней хранится аргумент (данные для вставки), поле для результата и Task, который кончится по окончании.

Работа bw организуется так (в вечном цикле):

1. Читаем первую запись из Channel (infinite timeout)
   
2. Создаем TaskCompletionSource с таймаутом и пока он не кончился читаем записи из Channel (без ожидания)
   
3. Собираем все собранные данные
   
4. Записываем их в БД
   
5. В каждый элемент записываем результат и уведомляем о готовности
   

Бесшовно добавить эту функциональность можно с помощью декоратора.

Единственная проблема в данном случае - ошибки вставки. Если делать это единой транзакцией, то ошибка в 1 инвалидирует все. Но это можно обойти fallback'ом - если произошла ошибка, то вставляем по одному и ошибку возвращаем только тем, у кого они возникли

Все просто - ты с клиента передаешь JSON объект, а принимаешь на сервере строку.
Вот и не сходятся типы.
Либо делай DTO на сервере, либо передавай строку.

Форма отправляется в теле, а ты хочешь ее передать через путь.
Тег action у form - статический, он не меняется (js тут нет), поэтому он должен быть известен с самого начала.

Тут 2 решения:
1. Переделывай все под js (сам все вставляй и прописывай)
2. Измени способ передачи формы: путь статический (без параметров пути подставляемых), а форма через [FromForm]

Сложные объекты, как раз могут передаваться, просто надо сделать формы другим образом. Скорее всего ты в этот asp-form передаешь всю модель. Предполагаю, что вся модель - это Address.
Да, из вложенных сложных структур плохо создаются формы. Для решения тебе надо будет форму вручную: все поля и их связь с моделью прописывать самому. Есть шаблонные помощники (Html.EditorFor и другие) - используй их.
Например, так (внимание, написал по воспоминаниям, может даже не компилироваться)

@Html.BeginForm() 
{
      <label>Страна</label>
      @Html.EditorForModel(x => x.Country)
      <label>Город</label>
      @Html.EditorForModel(x => x.City)
}

Кроме этого, есть пара других советов:
1. Создай специальные DTO классы, которые будут потом отображаться в эти объекты БД.
2. Раз ты делаешь через asp-form, то лушче добавь специальные атрибуты валидации: EmailAddress, Range и т.д.

P.S. в 1 пункте проблема глубже, чем простой маппинг. Если делать такой подход, который показан:
- Изменения схемы БД потребуют изменения UI
- Клиент может передать данные, о которых он знать не должен (например, добавишь новое поле куда-нибудь и оно случайно обновится)

Случаев использования много. В некоторых без него не обойтись.
Например:
- Зависимость необязательна
- Есть множество реализаций, а не 1
- Отложенное создание

Если не хочешь использовать - не используй

нормально себя чувствует.

Работает и не трогай

Middleware - это часть ASP.NET Core. Они занимаются обработкой HTTP запроса, могут его изменять/дополнять. Например, производить авторизацию или, если запрос пришел от прокси, то разворачивать отображать HTTP заголовки
Фильтры - это часть MVC, фреймворка внутри ASP.NET Core. Т.е. они часть контроллеров и предназначаются только для них, но могут работать и как Middleware (HttpContext поле доступно). Дополнительно, у них есть иерархия вызовов, в зависимости от типа фильтра, а middleware вызываются каждая и в зависимости от порядка их регистрации

В докерфайле не вижу слоя с рантаймом - только sdk.
Посмотри шаблон тут - https://learn.microsoft.com/ru-ru/dotnet/core/dock...

ViewData - это инструмент из ASP.NET Core MVC - старых MVC проектов. Он нужен, чтобы обойти строгую типизацию и передавать опциональные параметры.
PageModel - это уже новый фреймворк, который построен поверх MVC и сделан на упор в одностраничник, т.е. мы сразу можем что на странице должно быть отображено. Поэтому ViewData уже не особо нужен.

В итоге, использовать ViewData стоит если есть какие-то опциональные, transient данные, которые можно использовать. В примерах это заголовок страницы.

Url.Action принимает аргумент object? values (последний). В него нужно передать параметры для обработчика MVC контроллера. Передавать в виде анонимного объекта.
Для твоего случая это будет в виде:

@foreach (var item in Model)
    {
        <tr onclick="location.href='@Url.Action("ViewOrder", "Home", new { id = item.Id })'">
            <td>@item.Id</td>
            <td>@item.CitySender</td>
            <td>@item.AdressSender</td>
            <td>@item.CityRecipient</td>
            <td>@item.AdressRecipient</td>
            <td>@item.Weight</td>
            <td>@item.Date</td>
        </tr>
    }

Этот item.Id будет передаваться параметром в обработчик контроллера через параметр, который называется id.
Например, в этотpublic IActionResult ViewOrder(int id)

А откуда другой сервис знает, какие КЛАССЫ/ОБЪЕКТЫ есть в другом сервисе?
Если нужно кидать такое-же исключение на сервисе клиенте, то нужно это исключение там и создать.

А вообще, для своих типов исключений необходимо использовать GRPC_STATUS_UNKNOWN. В документации так и написано:

Server threw an exception (or did something other than returning a status code to terminate the RPC)

Решение только одно - в каждом сервисе писать свои обработчики таких исключений и свои классы исключений

Метод расширения GetDisplayUrl() у Request объекта (если это MVC)

[ApiController]
[Route("[controller]")]
public class SampleController : ControllerBase
{
    [HttpGet("")]
    public IActionResult GetPath()
    {
        return Ok( Request.GetDisplayUrl() );
    }
}

как их можно и нужно применить на практике?

Применять их никак не нужно. Платформа сама решит в каком режиме ей нужно работать.
Такая сейчас идет политика разработки: "просто пиши код, а остальное на нас"