Why using a DTO instead of an entity?
Using a DTO could be very complex if this one is modified on the client side and if you want to save your changes.
So in this case, I definitively prefer directly use my entities and, in case, having many models with, sometimes, just some pieces of the entire entity. (I will write about it in a future post)
However, for read only classes, it could be very useful:
- to send some aggregates (even if we can do it using WAQS specifications)
- to use some classes that are not persisted
We previously saw that we can use DTO in LINQ To WAQS queries.
In some cases, we want to expose DTO or collection of DTO through WCF methods.
For this, we could use the fact that the WCF Service is partial but we won’t talk about it here.
In our case, we will use Service methods which return DTO.
These ones would be able to use some Calculated properties on DTO but the business logic won’t be use in the client in this case (the calculation will be made on the server and only the value will be send to the client).