Is it possible to make a service that takes an IList<DTOType> instead of having to create a wrapper DTO with the list in it? I’m thinking that this could be useful if I wanted to expose services that allows me to either create a single entity by Post(DtoType) or batch create several by Post(IList<DtoType>). While I could just create a DtoTypeCollection class and accept that one for my batch creation this could cause quite a lot of extra types. Is it possible to do this or is it impossible/a bad idea?
I strongly recommend against using Interfaces in Services DTO’s: http://stackoverflow.com/a/10759250/85785 Even interfaces on POCO models is rarely a good idea since they shouldn’t be mocked themselves, IList<T> is especially useless since it’s almost always the List<T> concrete type which it needs to be casted to, to make use of many of the useful concrete List<T> APIs.
Just create a specific Request DTOs like any other Service, you can inherit List<T> to help with this:
public class DtoTypes : List<DtoType> {}
Fredrik Forssen:
Hm, good point. I should stop using IList in my services.
Though I’m a bit curious as to what is the reason that a type inheriting from List<DtoType> gets mapped correctly but a “pure” List<DtoType> does not?
Request DTO’s is the external facing service contract for your Services which need to be a uniquely-named and a non-generic type.
Fredrik Forssen:
Alright 
Thanks
Ryan Britton:
Can I just ask your opinion on something regarding this, Demis?
I can see your point of view in all the supporting material you’ve produced on the subject - but what about a case where the architecture strategy attempts to push all technological dependencies out of the business domain (where those business classes/entities/commands may be referenced by a servicebus worker in one context, persisted to a RavenDB database in another, used in a ServiceStack API in another)…
would you in this case use automappers and the like to map objects wherever they cross a boundary? it seems like an invitation for mapping mismatches, performance degradation, omitted properties, versioning issues etc… we could use simple Poco’s and manually create the routes when we create the API modules, and not decorate the entities with self-documenting Swagger attributes - but that seems such a shame, and counter-intuitive to SS’s structure of focusing on the message as the contract…
How would you handle this architecturally?