Should a client application communicate to a WCF service using real model classes or DTO objects?

Question

I understand that my DDD model project should be totally isolated and not reference any other layers of my application, and that my WCF service will contain DTO versions of the real model object with all the special attributes required by WCF services. The service will also reference the model and know how to translate between the DTO and "real" model objects.

What I want to know is whether a client application that is consuming this service should communicate with it using the DTO objects or real model objects? Should the client application be responsible for converting the DTO objects it receives from the service to model versions, or is that something that should be build into the service so that the client doesn't deal with the DTO objects directly?

I was thinking of creating a wrapper class that wraps an instance of a service and exposes the same functionality but as model objects rather then the DTO versions. Good idea? Bad idea?

Answer 1

Following articles should answer on your question

• Why You Shouldn’t Expose Your Entities Through Your Services
• DTO’s Should Transfer Data, Not Entities

Don't forgot take a look on Microsoft's and Martin Fowler's explanation about Data Transfer Object

Additionally. Be carefully on client side, dto changes should not lead to considerable coding

Answer 2

WCF does not understand 'real model classes' it only understands DTOs. The client code will have to understand these DTOs (or serialized payload) one way or another. So your question is whether you can use the same domain model classes from both client and server.

I was thinking of creating a wrapper class that wraps an instance of a service and exposes the same functionality but as model objects rather then the DTO versions. Good idea? Bad idea?

It depends on what type of application you are building and what deployment restrictions you have.

Referencing domain objects directly from both client and server means that you will have to upgrade them simultaneously. If your 'User' entity for example has a 'Name' attribute and you decide to split it into 'First' and 'Last' you will need to update client, server and data store at the same time. This is just a simple example, changes in model behavior may be even more problematic. Your approach seems OK if you are ready to redeploy the whole stack when something changes. In this case you can even try to avoid 'wrapper' and try to have this code as an alternative repository implementation. In other words you can try having two repository implementations: one for client and one for service. Client repository implementation will use WCF service as underlying data store. Repository implementation used by service will use the actual data store.

On the other hand, it may be a good idea to isolate clients from the changes on the server. In this case your main domain model is only referenced by service and is exposed to client as client-specific DTOs. This way you are free to evolve your domain model and service code without affecting clients. The client will probably have its own version of the model classes, 'sub-model' if you will, that it will populate based on DTO it received from the server.