Понимание жизненного цикла запроса и механизма маршрутизации в стеке сервисов

Question

Справочная информация (вы можете пропустить этот бит, он здесь на всякий случай, если вам нужен контекст)

Я видел по таким вопросам ServiceStack CRUD Документация по маршрутизации службы в документации есть странный способ объяснить что-то, что сводит то, к чему я привык (WebApi и маршрутизация на основе контроллера), к маршрутизируемому механизму, ориентированному на сообщения, что требует от нас определения запроса, ответа и класса обслуживания с помощью методов, чтобы обрабатывать каждый запрос.

Я нахожусь в процессе преобразования существующей кодовой базы из сервисов на основе WebAPI + OData в стек сервисов, чтобы определить различия / изменения моделирования, которые требуются для двух проектов.

Проблемный домен

В настоящее время я делаю много запросов, которые на самом деле не требуют каких-либо параметров (простых запросов get), но я вынужден одновременно создавать, создавать экземпляры и затем передать метод обслуживания DTO в этой ситуации, так как без такого DTO я не могу определить ро т.

Почему? это сбивает с толку!

Какова взаимосвязь между DTO, методами в сервисе и маршрутизацией / обработкой запроса, потому что в настоящее время у меня есть много классов "сервиса" в моем существующем стеке, которые в основном .. .

public class FooService : CRUDService<Foo> { /* specifics for Foos */ }

public abstract class CRUDService<T> : ICRUDService<T>
{
    public T GetById(object Id) { ... }
    public IEnumerable<T> GetAll() { ... }
    public T Add(T newT) { ... }
    public T Update(T newVersion) { ... }
    public bool Delete(object Id) { ... }
}

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

Это заставляет меня думать, что я Я должен прибегнуть к шаблонам T4, чтобы сгенерировать различные DTO, которые экономят мне время, пока запускают сотни практически пустых DTO.

Мой вопрос (ы)

Это сводится к тому, Как я могу преобразовать мою кодовую базу?

, в которой говорится, что «части» этого вопрос действительно подвопросы, такие как:

• Какова лучшая практика здесь?
• Я что-то упустил или у меня много работы по созданию пустых котлов DTO?
• Как стека Service связывает все эти вещи?

Мне сказали, что это "лучше, чем черный ящик OData / EF", но это на первый взгляд, кажется, скрывает тонна деталей реализации. Если только я не смущен чем-то в духе дизайна.

Answer 1

Каждый Сервис в ServiceStack требует конкретного запроса DTO, который используется для определения вашего контракта на Сервис.

Поскольку ServiceStack является структурой служб на основе сообщений, DTO с типизированным запросом является основополагающим в том, как работает ServiceStack, который "захватывает запрос", с которым вызываются службы, и который также передается через все фильтры ServiceStack. , например:

Запрос DTO - это также все, что необходимо для вызова Сервиса с любого клиента, включая Клиенты MQ :

И следуя Физической структуре проекта , Шаблоны проектов ServiceStack настроены на то, где все DTO хранятся в проекте ServiceModel без зависимостей / impl, который ServiceStack . NET generi c клиенты службы могут ссылаться напрямую, чтобы включить сквозной типизированный API без кода -gen, например:

var response = client.Get(new MyRequest { ... });

Запрос DTO, являющийся «сообщением», использует POCO DTO для определения своего контракта, который лучше подходит для управления версиями , поскольку они могут быть расширены без b повторное использование существующих классов, а так как Request DTO является определением и отправной точкой для вашего Сервиса, это также то, что большинство других функций ServiceStack является встроенным, не говоря уже о его важности.

Sharp Script для генерации кода

Если у вас так много CRUD-сервисов, что вы хотите sh для автоматического создания DTO для них, я бы рекомендовал взглянуть на # Script , который является динамическим c. NET Язык сценариев, в котором по умолчанию используется режим языка шаблонов, в котором используется привычный синтаксис JS для выражений и идеальный синтаксис рулей для блоков для шаблонов.

The поддержка автономных скриптов включает поддержку Live Preview, мгновенная обратная связь которой делает его очень продуктивной, а также включает в себя встроенную поддержку запросов к базам данных .

Хотя OrmLite - это код Первый ORM включает поддержку T4 для первоначального создания моделей данных.

Предварительный просмотр AutoCRUD

Поскольку вы хотите создать несколько CRUD-сервисов, вы можете воспользоваться предварительной версией AutoCRUD , которая теперь доступна на MyGet .

Концептуально это то же самое, что и «Auto Query», где вам просто нужно реализовать определение Request DTO для ваших API таблиц БД, а AutoQuery автоматически обеспечивает реализацию для Сервиса.