Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
From my perspective, the Data Services and their query approach is useful when querying simple object graphs from your server-side domain model. But when you want to query complex dependencies I couldn’t create anything good out of it.
The classic DTO approach is fine-grained and can handle everything, but the downside is that you have to create Dto classes for every type of server-request which is time consuming and you have to synchronize the Dto type with your domain entity/business logic.
Depends on your definition of ‘better’ – whether this is means quicker to market, or an easier to maintain application in the long run.
Hand-crafting DTO’s will mean the initial development effort will probably be longer than using a tool such as WCF Data Services. However, by exposing only DTO’s your application will be more decoupled from the internal domain model than WCF Data Services, so future maintenance fixes will probably be easier and shorter.
I would tend towards DTO’s if you have enough time and budget during initial development as money will be saved if the application lives for long enough, and it will be easier to fix/modify. Also using tools such as Automapper can alleviate many of the pain points associated with mapping between domain objects and DTOs.