ServiceStack:URL中是否可以指定基于上下文的路由? [英] ServiceStack: Is context based routing specified in the URL possible?

问题描述

我希望保留以前使用OData服务但通过ServiceStack公开的服务层在我的代码库中曾经拥有的大量功能，假设我实现了服务逻辑，我不想当这基本上是我要实现的目标时，请为请求添加大量新的DTO，除非框架强迫"我声明一堆额外的类而不带来任何功能上的好处...

I'm looking to retain a ton of functionality I used to have in my codebase from the service layer that I exposed previously using OData services but through ServiceStack, assuming I implement the service logic, I don't want to have to make a ton of new DTO's for requests when this is essentially what i'm trying to achieve unless the framework "forces" me to declare a bunch of extra classes for no functional gain ...

    [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) { ... }
    } 

我能看到的另一种实现此方法的方法是基本上必须创建一个FooRequest DTO，该DTO从此处的泛型继承而来，并且不添加任何内容.

The only other way I can see to implement this is to basically have to create a FooRequest DTO that inherits from the generic one here and adds nothing.

尽管在某些情况下可能是这种情况，但对于我必须迁移的数百个端点中的大部分而言，这似乎是浪费的，并且可能需要我不得不进行代码生成，但是Service Stack声称不是需要".

Whilst this might be the case in some scenarios, for the bulk of the hundreds of endpoints I have to migrate this just seems wasteful and likely will require to me having to result to code generation, something Service Stack claims "isn't needed".

我的处境变得更糟，因为我需要考虑多个数据上下文" ...

My situation is made worse because I have "multiple data contexts" to consider for example ...

// 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的实现，我只需要添加每个新类即可为堆栈中的该类型数据添加自定义点.

... with my OData based implementation I only need to add each new class to add a point of customisation for that type of data in the stack.

使用ServiceStack似乎仍然可以实现服务类(我认为，但是我不清楚路由的工作方式)……我感到困惑的是，了解请求DTO基本上都相同请求，但似乎无法根据URL中的某些tpye信息进行路由.

With ServiceStack this still seems to be possible regarding service classes (i think, but i'm not clear on how the routing works) ... where I get confused is understanding the request DTOs which are basically the same in all get requests but seemingly not routeable based on some tpye information in the URL.

理想情况下，我想通过使用HTTP谓词和URL中的[Route(〜/{Context}/{Type}")]之类的组合，将标准Request DTO路由到服务方法.这就是DTO上的属性用法.

Ideally I would like to route a standard Request DTO to a service method by a combination of the HTTP verb used and then something like [Route("~/{Context}/{Type}")] in the url (with that being the attribute usage on the DTO).

我感觉到ServiceStack不能像这样工作，并且要求我为每个服务上的每个方法定义一个新的DTO，而我将不得不定义一堆新的DTO.只是为了满足框架需求而已，没有新的实现细节.

I get the feeling though that ServiceStack doesn't work like this and is going to require me to define a new DTO for literally every method on every service and i'm going to have to define a bunch of new services that don't exist with no new implementation details in them just to satisfy the frameworks needs.

还是我在如何使用此处的框架方面避免了一些技巧来避免这项工作?

Or am i missing some trick in how to use the framework here to avoid this work?

推荐答案

您可以有多个Service基类，但是您的Request DTO不能是通用的，它必须是具体的Request DTO，但是它可以继承基类，例如所有自动查询RDBMS服务都继承自QueryDb<T>或

You can have multiple Service base classes but your Request DTO cannot be generic, it has to be a concrete Request DTO, but it can inherit base classes, e.g. All AutoQuery RDBMS Services inherit from QueryDb<T> or QueryDb.

您的路线应以/开头(即不是~/)，并且您可以有一个接受任何类型的Parameter:

Your Route should start with / (i.e. not ~/) and you could have a single Parameter that accepts any Type:

[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; }
}

可以通过以下方式调用:

That can be called with:

GET /data/Anything

但是您的服务应具有相同的返回类型(即遵守其服务合同)，因此除非您返回相同的非结构化数据响应(如Dictionary<string,object>，List<object>等)，否则通配符服务将无用./p>

But your Service should have the same return Type (i.e. adhere to its Service Contract) so a wildcard Service is not going to be useful unless you return the same unstructured Data response like Dictionary<string,object>, List<object>, etc.

我感觉到ServiceStack不能像这样工作，并且要求我为每个服务上的每个方法定义一个新的DTO，而我将不得不定义一堆新的DTO.只是为了满足框架需求而已，没有新的实现细节.

I get the feeling though that ServiceStack doesn't work like this and is going to require me to define a new DTO for literally every method on every service and i'm going to have to define a bunch of new services that don't exist with no new implementation details in them just to satisfy the frameworks needs.

是，ServiceStack要求每个服务都由其请求DTO定义，该请求DTO是描述该服务合同的主权限.这不仅仅是安抚框架的要求，请求DTO"是调用消息的消息.服务，这是通用服务客户端唯一需要做的事情send 来调用服务，如果该服务不存在，则无法发送；如果没有类型，则也不能具有Typed API(无代码源).

Yes ServiceStack Requires every Service is defined by its Request DTO which is the master authority describing that Services contract. This is not just a requirement to appease the Framework, the Request DTO is the message that invokes a Service, which is the only thing generic Service Clients need to send to invoke a Service, which it can't send if it doesn't exist, nor can it have a Typed API (without code-gen) if there are no types.

这篇关于ServiceStack:URL中是否可以指定基于上下文的路由?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！