tags:

views:

405

answers:

3

I am considering to use DTOs instead of passing around my domain objects. I have read several posts here as well as elsewhere, and i understand there are several approaches to getting this done.

If i only have about 10 domain classes in all, and considering that i want to use DTOs rather than domain objects for consumption in my Views (WPF front ends), what is the recommended approach. I think using tools like automapper etc maybe an overkill for my situation. So i am thinking of writing my custom mapper class that will have methods for converting a domain type to a DTO type.

What is the best way to do this, are there any sample to get me started to do this?

Second question: When writing those methods that will create DTOs, how do i deal with setting up all the data, especially when the domain type has references to other domain objects? Do i write equivalent properties in the DTO for mapping to those refernece types in the domain class? Please ask if i have not put my second question in proper words. But i think you understand what i am trying to ask.

Thrid question: When writing DTOs, should i write multiple DTOs, each containing partial data for a given domain model, so that each of it can be used to cater to a specific View's requirement, or should the DTO have all the data that are there in the corresponding model class.

A: 

I'm going to assume that your domain model objects have a primary key ID that may correspond to the ID's from the database or store they came from.

If the above is true, then your DTO will overcome type referecning to other DTO's like your domain objects do, in the form of a foreign key ID. So an OrderLine.OrderHeader relationship on the domain object, will be OrderLine.OrderHeaderId cin the DTO.

Hope that helps.

Can I ask why you have chosen to use DTO's instead of your rich domain objects in the view?

Martin Blore
Can the DTOs have ID properties in them? - i.e. OrderlineID in your sample. I thought DTOs are fully self contained data objects which won;t have any reference to database,and other external dependencies.As for why DTOs, my project will eveolve into a large system in future, and i want to ensure I build it now to adhere to being able to expose data over web service requests etc in future. Beeter to follow good practise from day 0 i suppose.Do you have any idea for my 3rd question (which i added only a few minute back).
+1  A: 

I'm kind of using DTOs in a project. I tend to make the DTOs only to show the data I need for an specified view. I fetch all the data shown in the view in my data access class. For example, I may have an Order object which references a Client object:

public class Client{
    public int Id{get;set;}
    public string Name{get;set;}
}

public class Order{
    public int OrderID{get;set;}
    public Client client{get;set;}
    public double Total{get;set;}
    public IEnumerable<OrderLine> lines {get;set;}
}

Then in my OrderListDTO I may have something like:

public class OrderListDTO{
    public int OrderId{get;set;}
    public string ClientName{get;set;}
    ...
 }

Which are the fields I want to show in my view. I fetch all these fields in my Database access code so I don't have to bother with entity asociations in my view or controller code.

Carles
A: 

@Martin Blore How are you updating OrderLineDTO with NHibernate?

For some reason I don't know how to comment, so sorry for the post.

Al Bundy