DTO (Data Transfer Objects)

A Data Transfer Object, or DTO is a design pattern for a very specific type of object that is used to transfer data between different parts of your application.

A DTO is just for temporarily storing information whilst it is in transit. Therefor a DTO has limited behaviour, only that of storing, retrieving, validating, and internal consistency checking of its own data. They should have no responsibility in terms of security, transaction, and business logic. This de-coupling of storage and business logic will enable us to use the same DTO in different contexts.

DTOs come in two different types: generic collections, or custom objects.

Generic Collections

Generic collections, eg. Dictionaries or Arrays, are advantageous in that you only require a single DTO for all your data transfer needs. The main disadvantage is that the client has to access fields either by position index (in the case of Arrays), or by key (in the case of Dictionaries). A further problem is that as the type of objects in a collection is unknown. In a future revision of Actionscript Arrays will be typed, which will only allow collections to store data of one type. This can lead to items being stored as a generic Object type, which can lead to subtle but fatal coding errors that cannot be detected at compile time.

The creation of a dynamic generic objects can be costly as Flash doesn’t know how much memory to allocate. By typing all your variables, Flash can then allocate the necessary memory for those variables and no more. This avoids the creation of a Hash Table and will therefor decrease memory consumption and increase performance.

Custom Objects

Creating a custom class for your DTOs provides strictly typed objects which allow for compile-time checking and support code editing features like FDTs “code assist” feature (ctrl + space). The only drawback is the creation of a large amount of DTOs that might be required for a large application.

Fields contained within a custom DTO should be of primitive/simple types eg. strings, booleans, etc. or arrays of those, and it may even contain other DTOs. As DTOs are meant to be temporary objects for transferring data, their fields should be immutable (read-only). Although this can be particularly difficult to achieve under certain circumstances.

1. package ch.forea.exampleDTO {
2. public class CardDTO{
3. private var _name:String;
4. private var _address:String;
5. private var _phone:String;
7. public function CardDTO(name:String, address:String, phone:String){
8. _name = name;
9. _address = address;
10. _phone = phone;
11. }
13. public function get name():String{
14. return _name;
15. }
16. public function get address():String{
17. return _address;
18. }
19. public function get phone():String{
20. return _phone;
21. }
22. }
23. }

The purpose of all this is to package all required information in to one package, therefor transferring everything in one call rather than multiple calls. This method can be advantageous if the call is to a remote system, as any further calls to the DTO are made locally to the client.



http://forea.ch/blog/2008/11/14/back-to-basics-the-data-transfer-object-dto/