Witam
Mam takie pytanie czy coś stoi na przeszkodzie, albo czy jest to dobry styl programowania jeśli encję oznaczymy jako IsSerializable i stanie się ona de facto DTO ??
Widziałem kilka przykładów gdzie po wykonanym zapytaniu w forze przepisywane są encje do DTO ?
Nie wydaje mi się to dobrym rozwiązaniem zwłaszcza, jeśli DTO == Encja tj. DTO ma takie same pola jak encja więc nie rozumiem takiego przepisywania ???
... a później z taką encją postępujesz, jak z DTO, czyli np. wysyłasz z serwera do klienta. I okazuje się nagle, że u klienta musisz mieć napisaną caaaałą obsługę encji i bazy danych, żeby w ogóle się skompilowało. Używamy oddzielnie reprezentacji danych do bazy i danych do klienta, żeby tego uniknąć.
Korzyścią dodatkową jest to, że klient może być cwany i zdekompilować sobie nasz kod, co umożliwi mu poznanie struktury bazy danych na podstawie DTO będących encjami. Jeśli ma DTO bez danych encji (zapytania, nazwy w bazie), to taka analiza niewiele mu da.
Jeśli encja==dto czyli piszesz przeglądarke do tabel w bazie to rzeczywiście nie ma co się wydurniać w DTO
U mnie aktualnie w projekcie jest tak, ze kazda encja posiada swoje DTO i te DTO-sy pakowane sa w CTO-sy. DTOsy sa reuzywalne. CTO-sy zazwyczaj pisane pod dialog.
Mniejsza o plusy i minusy takiego podejscia.
Ogolem uwazam ze mozna by sprobowac podejscia, zeby zamiast DTO-sow uzywac Entity. Ale wtedy walczysz z innymi problemami (np. trzeba pamietac o zainicjowaniu wszystkich kolekcji "lazy" OneToMany przed wyslaniem do klienta)
@xiatus właśnie w tym jest największa "zabawa" jeśli mam np encje Person i zawiera ona kolekcje dajmy na to Adress to jesli chcę sobie przesłać tylko encje Person to przesyłam tylko person jeśli chcę całą encje z Adresami to daję sobie w selekcie left join fetch i ok.
Hmm nie mogę znaleźć sensownej odpowiedzi na stosowanie DTO . Według mnie DTO daje nam dodatkowe narzuty. Np jeśli przykładowo mamy np DTO : PersonDTO to zawiera on w sobie DTO : AdressDTO i tak np przy zapisie do metody dajemy DTO i musimy potem w pętli wypełnić wszystkie adresy tego usera czyli inaczej em.find(addressID) a następnie przypisać itd itd . Jak dla mnie jest to nieuzasadnione ....
Nie rozumie też "jak wysyłasz z serwera do klienta" ?? W większości przypadku klientem jest przeglądarka internetowa więc co ma jedno do drugiego . Po drugie zazwyczaj DTO też jest 1 do 1 tak jak dana encja więc nie ma problemu dla klienta poznanie twojej struktury w takiej sytuacji chyba że piszesz specjalne zagmatwane DTO z niepotrzebnymi polami . Po 3 jak wysyłasz coś do klienta to przez web service albo RESTA to przecież przesyłasz xml albo gdzie mozesz ponadpisywać nazwy więc dalej nie wiem o co be ..