Temat: Transfer Object, TO, DTO (Obiekt Transferujący, Transfer...
DTO to tylko kontener danych, służący do ich przesłania między jedną warstwą a drugą (np. modelem a widokiem). Nic więcej.
Cały urok warstwowej architektury (warstwa jest bardzo szerokim pojęciem. Warstwa logiki i widoku" dla innej warstwy może być warstwą źródła danych, np. generator strony WWW może także generować XMLowy wykaz częstości słów na tej stronie dla modułu analitycznego) polega na tym, że każda z warstw jest maksymalnie niezależna - oczywiście przy dobrze wykonanym projekcie - od pozostałych, zatem można łączyć różne technologie. Np. źródłem danych może być plik XML, baza Oracle, MySQL, SQL Server, zwykły plik binarny, Datamart, etc. Sterownik może być napisany w dowolnym języku, np. C. Warstwa ORM, jeśli obecna, może być napisana w innym języku, np. C++. Warstwa modelu (logiki biznesowej), zasilanego danymi z poprzedniej warstwy, może być napisana np. w Javie, zaś widok... może nim być aplikacja "formsowa" (np. .NET WinForms, Java ze Swingiem, C++ z QT, C++ z MFC), może być strona WWW (np. JSP/JSF), może być WebService napisany jeszcze w czym innym, a nawet zespół serwomechanizmów i sterowników PLC, programowanych swoim natywnym językiem (assemblerem, drabinkowym, niskopoziomowym C, czym czymkolwiek innym).
A to jednocześnie wskazuję odpowiedź na postawione pytanie. To zależy, czy poszczególne warstwy zrozumieją to, co chce się przesłać w "deteoku". Czy C++ zrozumie w ogóle "string", czy woli raczej "char zmienna[]"? A może assembler w ogóle nie zrozumie naszego "Long", tylko woli "DWORD"? Czy poruszamy się w zakresie 50 różnych technologii, gdzie "string stringowi nie równy" (a to przecież KOLEKCJA bajtó :) ), czy np. tylko na platformie .NET, gdzie możemy przesyłać np. typowane DataSety? A może to J2EE i między "binsami" a "ricz fejsami" możemy przesyłać wprost beany? Przecież Java mówi o takich sytuacjach wprost - stosować się do standardu POJO (a w .NET - POCO)
W reczywistym świecie takimi "deteokami" są np. pliki CSV (nie Excel), TXT, względnie RTF (nie Word), EMF (nie Corel Draw), RAW/BMP (nie Corel Photo Paint).
DTO nie musi być banalnie prosty (np. ograniczony tylko do pól, gdzie kolekcje są niedopuszczalne; wówczas przesłanie kolekcji to repetowanie wysyłki kolejnych DTOków), może zawierać złożoną strukturę danych, ale powinien zawierać dane w formacie uniwersalnym dla jak największej grupy odbiorców i nie zawierać jakichkolwiek nawiązań do konkretnej technologii, która może nie być rozumiana przez inne warstwy.
Np. w .NETcie serializować bez problemu mozna pewne typy proste - tablice bajtów, stringi. Ale już taki obrazek musi być zamieniony na tablicę bajtów. "Wskaźniki" na tablice bajtów można umieścić w innej tablicy bajtów i już mamy kolekcję kolekcji bajtów, czylo kolekcję obrazków.
Z mojej praktyki i wielu dyskusji technologicznych wynika, że do DTOka możemy wrzucić tyle, ile zrozumieją wykorzystywane przez nas technologie. Nie trzeba planować na wszystkie najgorsze przypadki, bo wtedy ynawet ów string okaże się "nieserializowalny".
http://msdn.microsoft.com/en-us/library/ms978717.aspx
A DTO is a simple container for a set of aggregated data that needs to be transferred across a process or network boundary. It should contain no business logic and limit its behavior to activities such as internal consistency checking and basic validation. Be careful not to make the DTO depend on any new classes as a result of implementing these methods.
When designing a data transfer object, you have two primary choices: use a generic collection or create a custom object with explicit getter and setter methods.
A generic collection has the advantage that you only need a single class to fit any data transfer purpose throughout the whole application. Furthermore, collection classes (for example, simple arrays or hashmaps) are built into almost all language libraries, so you do not have to code new classes at all. The main drawback of using collection objects for DTOs is that the client has to access fields inside the collection either by position index (in the case of a simple array) or by element name (in the case of a keyed collection). Also, collections store items of the same type (usually the most generic Object type), which can lead to subtle but fatal coding errors that cannot be detected at compile time.
Creating custom classes for each DTO provides strongly-typed objects that the client application can access exactly like any other object, so they provide compile-time checking and support code editor features such as Microsoft IntelliSense technology. The main drawback is that you could end up having to code a large number of these classes if your application makes a lot of remote calls
http://java.sun.com/blueprints/corej2eepatterns/Patter...
public class ResourceDetailsTO {
public String resourceId;
public String lastName;
public String firstName;
public String department;
public String grade;
// other data...
[b]public Collection commitments;
public Collection blockoutTimes;
public Collection skillSets;[/b]
}
пропозиції роботи
