🚀 go-pugleaf

"Przemek Pokrywka" <adres@zastrzezony.com> wrote:

> Dziękuję obydwu Panom za wyjaśnienia, jednak nie bardzo o to mi chodziło. 
> Pisząc, że wydaje mi się, że transfer objects nie są  obiektowe, miałem na 
> myśli to, że są one typowymi pojemnikami na dane,

Dokladnie tak jest. Nie sadze jednak, aby problemy, ktore TO rozwiazuje 
(przynajmniej w kontekscie Distributed Components), dalo sie rozwiazac 
inaczej.

> Co by mogło być ciekawe (a możliwe do zrealizowania w technologii 
> obiektowej), to zachowanie, migrujące wraz z obiektem na inny węzeł sieci 
> i oddziałujące z nowym kontekstem. Tego jednak nie da się uświadczyć w 
> J2EE.

Jest to jak najbardziej wykonalne, w koncu klasa w Javie to tylko zlepek 
bitow, ktore bez problemow mozna przeslac po sieci. Nie o to jednak chodzi. 
W (wiekszosci) przypadkow bowiem kontekts takiego obiektu nie jest mozliwy 
do przeslania, a nawet gdyby bylo to mozliwe, zwykle nie jest pozadane. 
Rzecz w tym bowiem, aby w konwersacji "klient-serwer" kazda ze stron 
pozostala w swoim srodowisku kontekstowym. W przeciwnym wypadku sens takiej 
architektury zaczyna byc problematyczny.

Pomiedzy klientem i serwerem, przesyla sie wiec tylko dane. A do tego 
wlasnie sluza Trasfer Objects.

Oczywiscie powyzsze bazuje na uogolnieniach. Ale "J2EE patterns" generalnie 
wlasnie takich uogolnien dotycza.

Robert Perlinski