These are just my experiences :-) The chosen solution is Use Case dependent and it's possible that multiple patterns fit within 1 system.
- Generally speaking the DTO (Data Transfer Object) is rarely a ViewModel too. Of course with partial classes you can solve this problem, but by default a generated DTO doesn't support Property Changed notification, again it can be added by the proxy
generation tool or by a custom T4 template and so on.
- On the wire within a DTO only Id values are travelling for enum types. These are resolved to localized!! strings on the client, so here, the DTO can not be the ViewModel itself. My client side classes are heavily attributed, DisplayAttribute, various
Validation attributes applied to members of a ViewModel.
- Regarding the WHERE to translate them...I've a Service factory class which creates the proxy as needed and I've a "local service" class which encapsulates the real service call. In this class you can do client side caching and object translation
too. This way the invoker (which is usally a view's command handler) gets a ViewModel back (or a propageted exception).
- Regarding the HOW to translate them...you can have a 1-1 translator classes or you can add a constructor to your ViewModel which accepts one or more DTO to do the mapping.
I hope I give some insights from my point of view which can help you in your decisions!