You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Derek Hohls <DH...@csir.co.za> on 2004/05/07 08:18:08 UTC
RE: Business Objects vs Data Objects [was Re: JXTemplates -
what' s in a name?]
Yes; this confused me too - are there now:
DAO - used to read data from DB
DTO - to transfer data to app
BO - to store/manipulate data for a particular "thing"
and how do any/all these interrelate with each and
the Forms framework...
If someone can post a reasonably clear explanation of
all this, with links to examples/references, I think its
worth adding at least to Wiki, if not the main docs.
Derek
>>> dbols@osirion.be 2004/05/07 06:51:20 AM >>>
Could in your example valueObject be a BO (Business Object) or is
valueObject a DTO which is used to populate a BO?
When using the Flow/CForm solution who is used (BO or DTO) to bind data
to
the form?
--
Danny
> -----Original Message-----
> From: Ugo Cei [mailto:u.cei@cbim.it]
> Sent: donderdag 6 mei 2004 19:24
> To: users@cocoon.apache.org
> Subject: Re: Business Objects vs Data Objects [was Re: JXTemplates -
> what' s in a name?]
>
>
> Ralph Goers wrote:
> > Isn't what you wrote just a restatement of what I wrote? Perhaps
my
> > statements just weren't clear.
>
> I don't think so. You said:
>
> "In my environment a DAO is the object that is the result of reading
> from the database (or some other source)."
>
> To me this means (more or less) that you read from the db and as a
> result you get an object whose fields contain values from the
database
> columns.
>
> If this is what you mean, it isn't a DAO. This is a DAO:
>
> Dao myDao = daoFactory.getDao();
> SomeClass valueObject = myDao.find(pk);
>
> "valueObject" is the result of reading. "myDao" is what you use
> to read it.
> Sorry to be nitpicking, but since this thread revolves around
> nomenclature, we'd better agree on what each term means exactly.
>
> Ugo
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Business Objects vs Data Objects [was Re: JXTemplates - what'
s in a name?]
Posted by Ugo Cei <u....@cbim.it>.
Bertrand Delacretaz wrote:
> Of course, in a complex java app it would be good to have a clean
> structure using these concepts, but if you're trying to understand the
> relationship between Forms and java code, you should not worry about them.
To Derek: I couldn't come up with a better explanation than Bertrand's,
so I won't add anything to it.
Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Business Objects vs Data Objects [was Re: JXTemplates - what' s in a name?]
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 7 mai 04, à 08:18, Derek Hohls a écrit :
> Yes; this confused me too - are there now:
> DAO - used to read data from DB
> DTO - to transfer data to app
> BO - to store/manipulate data for a particular "thing"
>
> and how do any/all these interrelate with each and
> the Forms framework...
IMHO you shouldn't let these distinctions confuse you, as they are not
very relevant to the interactions between Forms and java objects.
Assuming your java object contains a field X, what Forms does (through
Forms bindings that you define), is to use a getX() method to read the
value of X when form.load is called, and setX() to set the value of X
when form.save is called. That's it - as long as the java object
implements these methods you're fine.
Forms does not care the least whether you consider the java object in
question to be DAO, DTO, BO or whatever O one wants to call it. These
distinctions are only relevant to the organization of the java code,
which Cocoon does not force you to write in a particular way.
Of course, in a complex java app it would be good to have a clean
structure using these concepts, but if you're trying to understand the
relationship between Forms and java code, you should not worry about
them.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Business Objects vs Data Objects [was Re: JXTemplates -what'
s in a name?]
Posted by Antonio Gallardo <ag...@agssa.net>.
Derek Hohls dijo:
> Yes; this confused me too - are there now:
> DAO - used to read data from DB
> DTO - to transfer data to app
> BO - to store/manipulate data for a particular "thing"
>
> and how do any/all these interrelate with each and
> the Forms framework...
>
> If someone can post a reasonably clear explanation of
> all this, with links to examples/references, I think its
> worth adding at least to Wiki, if not the main docs.
Hi Derek:
It is almost a year old graph, a very simple one, but maybe it can help to
provide a big picture. The names are not the best as we are learning with
the time, but maybe can help a little:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105955717614416&w=2
(See the png attached).
I hope this help.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org