Re: I don't like Data Transfert Objects
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, Nationalitysenum, 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
Re: I don't like Data Transfert Objects
On Thu, 29 Nov 2007, Gervais wrote:
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.
When doing real remoting DTOs might make sense. With Wicket
pages I don't quite see how would that happen. We typically
have components looking up the data they need themselves,
using injected services. But obviously you might be in a
different situation.
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, .. ) {.. }
To me it seems as if that would just be hiding a design
problem of APage having too much responsibility (and thus
not following the single responsibility principle).
Anyway, this is getting off-topic, so maybe we'll have to
keep it down or get a room :)
student project, i must change the presentation layer for another web
presentation framework or Swing with remoting)
For remote client-server some DTOs might make sense, but as
with any optimisation you shouldn't do it too early.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: I don't like Data Transfert Objects
Hi Gervais Im not sure if you have understood the idea of the CompoundPropertyModel(CPM). You pass a simple domain class to it and it uses property expressions to retireve what ever requested. For example if you set a CPM on a page you may add a label using this new Label(label) this will create a property expression and call the acesssor getLabel(). If you do not want to expose / keep your domain class in memory you can chain a CPM and create your own forexample personModel, and in the scenes behind you could have your big model and call getPerson on that and keep an id there only for lookup. regards Nino Gervais wrote: Hi wicketers, I use Wicket since 2 weeks. Before wicket i have worked on many projects (Swing or Web apps) and try to find the best architecture. Now i'm learning Wicket and i have a big problem. I dont'like Data Transferts Objects. Many forms use more than one Bean, so i have asked you in a Getting Started mail on how to do that properly. James Perry give me this response : ... To answer your third qestion on how to bind more then one domain model to a form, I would recommend using the Data Transfer Object which has associations to the domain models you are binding. Then use a CompoundPropertyModel to access the associatios. ... Thank you James. But i don't like the the idea to Create a DataTransfertObject and give it to a new CompoundPropertyModel. I think the DTO is like a Model. So i need to create only one Model that contains all required beans and extends or implements a Model. What kind of model can i use for doing that in the better and the cleaner way ? Thank you -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I don't like Data Transfert Objects
Hi, 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. Thank you. [1] : http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html Nino Saturnino Martinez Vazquez Wael a écrit : Hi Gervais Im not sure if you have understood the idea of the CompoundPropertyModel(CPM). You pass a simple domain class to it and it uses property expressions to retireve what ever requested. For example if you set a CPM on a page you may add a label using this new Label(label) this will create a property expression and call the acesssor getLabel(). If you do not want to expose / keep your domain class in memory you can chain a CPM and create your own forexample personModel, and in the scenes behind you could have your big model and call getPerson on that and keep an id there only for lookup. regards Nino Gervais wrote: Hi wicketers, I use Wicket since 2 weeks. Before wicket i have worked on many projects (Swing or Web apps) and try to find the best architecture. Now i'm learning Wicket and i have a big problem. I dont'like Data Transferts Objects. Many forms use more than one Bean, so i have asked you in a Getting Started mail on how to do that properly. James Perry give me this response : ... To answer your third qestion on how to bind more then one domain model to a form, I would recommend using the Data Transfer Object which has associations to the domain models you are binding. Then use a CompoundPropertyModel to access the associatios. ... Thank you James. But i don't like the the idea to Create a DataTransfertObject and give it to a new CompoundPropertyModel. I think the DTO is like a Model. So i need to create only one Model that contains all required beans and extends or implements a Model. What kind of model can i use for doing that in the better and the cleaner way ? Thank you
Re: I don't like Data Transfert Objects
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 -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
