ServiceStack: возможна ли контекстная маршрутизация, указанная в URL? - PullRequest
Новая
       11

ServiceStack: возможна ли контекстная маршрутизация, указанная в URL?

2 голосов
/ 14 марта 2020

Я хочу сохранить тонну функциональности, которую я имел в своей кодовой базе из сервисного уровня, который я использовал ранее, используя сервисы OData, но через ServiceStack, предполагая, что я реализую сервисную логику c, я не хочу я должен сделать кучу новых DTO для запросов, когда это, по сути, то, чего я пытаюсь достичь, если фреймворк не «заставляет» меня объявлять кучу дополнительных классов без какой-либо функциональной выгоды ... 

    [Route("~/{Type}")]
    public class GetRequest
    {
        public string Type {get; set; }
        public string Select { get; set; }
        public string Expand { get; set; }
        public string Filter { get; set; }
        public string GroupBy { get; set; }
        public string OrderBy { get; set; }
    }

    public ServiceBase<T> : Service
    {
       public virtual IEnumerable<T> Get(GetRequest<T> request) { ... }
    } 

    public FooService : ServiceBase<Foo> 
    { 
       public override IEnumerable<Foo> Get(GetRequest<Foo> request) { ... }
    }

Единственный другой способ реализовать это - это создать Doo FooRequest, который наследует от generi c и ничего не добавляет.

Хотя это может иметь место в некоторых сценариях ios, для большей части сотен конечных точек, которые мне нужно перенести, это просто кажется расточительным и, скорее всего, потребует от меня необходимости генерировать код, что-то, по мнению Service Stack, "не нужно".

Моя ситуация усугубляется, потому что у меня есть «несколько контекстов данных» для рассмотрения, например ... 

// base implementation for all services, derives from ServiceStack Service
public abstract class ServiceBase<T> : Service { ... }

// core service then one concrete implementation off that 
public class CoreService<T> : ServiceBase<T> { ... }
public CoreFooService : CoreService<Foo> { ... }

/// b2b service then one concrete implementation off of that 
public class B2BService<T> : ServiceBase<T> { ... }
public class BarB2BService : B2BService<Bar> { ... }

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

С ServiceStack это все еще представляется возможным в отношении классов обслуживания (я думаю, но я не совсем понимаю, как работает маршрутизация) ... я запутался в понимании запросов DTO, которые в основном одинаковы во всех запросах get, но, по-видимому, не маршрутизируются на основе некоторой информации tpye в URL.

В идеале я хотел бы направить стандартный запрос DTO к методу службы, используя комбинацию используемого HTTP-глагола, а затем что-то вроде [Route ("~ / {Context} / {Type}")] в URL (при этом использование атрибутов в DTO).

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

Или я упускаю какую-то хитрость в том, как использовать фреймворк здесь, чтобы избежать этой работы?

1 Ответ

1 голос
/ 14 марта 2020

У вас может быть несколько базовых классов Service, но ваш запрос DTO не может быть обобщенным c, это должен быть конкретный запрос DTO, но он может наследовать базовые классы, например, все службы AutoQuery RDBMS наследуются от QueryDb<T> или QueryDb .

Ваш маршрут должен начинаться с / (т.е. не ~/), и у вас может быть один параметр, который принимает любой тип: 


[Route("/data/{Type}")]
public class GetData
{
    public string Type {get; set; }
    public string Select { get; set; }
    public string Expand { get; set; }
    public string Filter { get; set; }
    public string GroupBy { get; set; }
    public string OrderBy { get; set; }
}

Это можно вызвать с помощью: 

GET /data/Anything

Но ваша служба должна иметь такой же тип возврата (т.е. придерживаться своего контракта на обслуживание), поэтому подстановочная служба не будет полезна, если вы не вернете тот же неструктурированный ответ данных, как Dictionary<string,object>, List<object>, et c.

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

Да ServiceStack Требуется, чтобы каждая служба определялась ее запросом DTO, который является основным органом, описывающим этот контракт на услуги. Это не просто требование для умиротворения платформы, запрос DTO представляет собой сообщение, которое вызывает службу , которая является единственной вещью, которую generi c Клиенты службы должны отправить для вызова Сервис, который он не может отправить, если он не существует, и при этом он не может иметь Typed API (без code-gen), если нет типов.

...