Background (you might want to skip this bit, it's here just in case you want context)
I saw from questions like this ServiceStack CRUD Service routing Documentation that the documentation has a weird way of explaining something that takes what I'm used to (WebApi and controller based routing) to a message oriented routed mechanism requiring us to define a request, response, and a service class with methods in order to handle each and every request.
I'm in the process of converting an existing code base from WebAPI + OData based services to service stack to determine the difference / modelling changes that the two designs require.
The problem domain
There are many requests I currently make that don't really require any parameters (simple get requests) and yet i'm forced to both create, instantiate and then pass to a service method a DTO in this situation as without such a DTO I can't define the route.
Why? this is confusing!
What is the relationship between the DTO, the methods in a service and the routing / handling of a request because i currently have lots of "service" classes in my existing stack that are basically ...
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) { ... }
}
... how do i get from that for 100 or so services to making this a functional service stack implementation because at the moment my understanding is that I can't pass scalar values to any of these methods, I must always pass a DTO, the request DTO will define the route it handles and I must have a different request and response DTO for every possible operation that my API can perform.
This leaves me thinking I should resort to T4 templating to generate the various DTO's saving me time hand cranking hundreds of basically empty DTO's for now.
My question(s)
It boils down to How do I convert my codebase?
that said, the "sub parts" of this question are really sub questions like:
- What's best practice here?
- Am I missing something or is there a lot of work for me basically building empty boiler plate DTO's?
- How does Service stack wire all this stuff up?
I was told that it's "better than the black box of OData / EF" but this at face value appears to hide a ton of implementation details. Unless i'm just confused at something in the design ethos.
