Estoy buscando retener una tonelada de funcionalidad que solía tener en mi base de código de la capa de servicio que expuse anteriormente usando los servicios OData pero a través de ServiceStack, asumiendo que implemento la lógica del servicio, no quiero tener que hacer una tonelada de nuevos DTO para solicitudes cuando esto es esencialmente lo que estoy tratando de lograr a menos que el marco "me obligue" a declarar un montón de clases adicionales sin ganancia funcional ...
[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) { ... }
}
La única otra forma que puedo ver para implementar esto es básicamente tener que crear un DTO FooRequest que herede del genérico aquí y no agregue nada.
Si bien este podría ser el caso en algunos escenarios, para la mayor parte de los cientos de puntos finales que tengo que migrar, esto parece un desperdicio y probablemente me obligue a tener que generar código, algo que Service Stack afirma que "no es necesario".
Mi situación empeora porque tengo "múltiples contextos de datos" para considerar, por ejemplo ...
// 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> { ... }
... con mi implementación basada en OData solo necesito agregar cada nueva clase para agregar un punto de personalización para ese tipo de datos en la pila.
Con ServiceStack, esto todavía parece ser posible con respecto a las clases de servicio (creo, pero no tengo claro cómo funciona el enrutamiento) ... donde me confundo es entender los DTO de solicitud, que son básicamente los mismos en todas las solicitudes de obtención, pero aparentemente no se puede enrutar según alguna información tpye en la URL.
Idealmente, me gustaría enrutar un DTO de solicitud estándar a un método de servicio mediante una combinación del verbo HTTP utilizado y luego algo como [Ruta ("~ / {Contexto} / {Tipo}")] en la URL (siendo ese el uso de atributos en el DTO).
Sin embargo, tengo la sensación de que ServiceStack no funciona así y me va a requerir que defina un nuevo DTO para literalmente cada método en cada servicio y voy a tener que definir un montón de nuevos servicios que no existen. sin nuevos detalles de implementación en ellos solo para satisfacer las necesidades del framework.
¿O me falta algún truco sobre cómo usar el marco aquí para evitar este trabajo?