DTO is a design that can be not only in J2EE.
I like the idea that Wicket can manipulate directly domain objects but
not to give many objects to wicket page's.
I like that
public class APage extends WebPage {
public APage(ADomainBean bean) {.. }
But not
public class APage extends WebPage {
public APage(ADomainBean bean0, ANotherDomainBean bean1,
YetAnotherDimainBean bean2, .. ) {.. }
In my "test" form i need to use "Person", "Person", "Student",
"StudentFolder", "Nationalitys<enum>", and also some models for Radio (O
Father, O Mother, O Responsible, O Student Itself) or DropDown (French,
Dutch, English, German) that isn't in Domain beans.
So a DTO that contains all Beans and models is more efficient than many
beans and list as constructor args. (And also bacause my project is
student project, i must change the presentation layer for another web
presentation framework or Swing with remoting)
Timo Rantalaiho a écrit :
On Wed, 28 Nov 2007, Gervais wrote:
A have already understand the idea of the CPM. But i think it is boring
to write another class "just" for handling some properties or beans.
But now i have read "Core J2EE Patterns - Transfer Object[1]" and DTO
can give me more than "just handling some properties or beans". Now i
like Data Transfert Objects and i know why it is good to use it.
To give another point of view, I think that DTOs are a
design smell that should be avoided normally, at least in an
environment without remoting, and the Core J2EE Patterns
give me a vague memory of being depressing workarounds for
fundamental problems in the old J2EE (EJB 1 and 2 mostly)
versions ;)
In every Wicket project I've been in, we have had Wicket
manipulate our domain objects directly, and this has worked
in around 95 % of the cases. The rest we have handled case
by case. Surely your mileage may vary.
Best wishes,
Timo
