Remoting with DTOs

[dragonwell]

Continuting on the topic in thread678-1014576

We are going to have a Customer business object, and a serializable CustomerDTO data-transfer-object. A CustomerService class with a method like ListCustomers that returns a list of CustomerDTOs to the presentation layer.

How exactly does a CustomerDTO instance get created from a Customer business obejct? Is it just through brute force - go through each property and set the data, or is there some trick using meta-data or something? At worst the CustomerService gets a list of Customers from the business layer, loops through it and creates new CustomerDTOs and puts them in a new list and returns it. Is that the typical way?

Thanks

 

[chiph]

I've seen a couple of ways. One is brute-force, where you copy from your query results into each public property. Another is creating a custom attribute for each property that maps the property name to the column name.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[dragonwell]

Thanks, Chip. When you talk about queries and columns I think you might be talking about O/R Mapping. I AM using O/R mapping to go from database to business object - my question is how to go from business object to DTO. Now would you have another simple mapper that uses attributes and public properties to go back and forth? If so, which class has the attributes set on it's properties? Does a Customer business object have a "Name" property with an attribute that tells the mapper that the Name property maps to the "Name" property of the Customer DTO, or does the Customer DTO's property have the attribute that tells what property from the customer business object it maps to?

 

[chiph]

Substitute "Column" with any term you like. The problem is the same -- how to map from one object/structure to another.

If so, which class has the attributes set on it's properties?

Whichever one is easiest and makes the most sense for you. If you don't want the attributes visible in the main portion of your code, then put them on the business object. You could even put them on both, but that's probably overkill. ;-)

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[dragonwell]

Cool, it's making sense now. Thanks again.

 

[stevexff]

Fowler, in Patterns of Enterprise Architecture (PEAA) calls this object an assembler. It has methods like

createDTO(domainObject);
createDomainObject(DTO);
updateDomainObject(DTO);

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[dragonwell]

Thanks Steve. That's what I was looking for. That book's been in my wishlist for a while - guess it's time to order it.