You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Gervais <ge...@polymedis.com> on 2007/11/28 09:12:30 UTC
I don't like Data Transfert Objects
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
Posted by Timo Rantalaiho <Ti...@ri.fi>.
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 Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: I don't like Data Transfert Objects
Posted by Gervais <ge...@polymedis.com>.
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
>
>
Re: I don't like Data Transfert Objects
Posted by Timo Rantalaiho <Ti...@ri.fi>.
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 Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: I don't like Data Transfert Objects
Posted by Gervais <ge...@polymedis.com>.
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
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org