You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ralph Goers <Ra...@digitalinsight.com> on 2004/05/07 08:30:24 UTC

RE: Business Objects vs Data Objects [was Re: JXTemplates - what' s in a name?]

You should take a look at the J2EE patterns either at Sun's website or in
the book.  ValueObjects were renamed TransferObjects in the latest revision.
I seem to recall that my copy of the Patterns book has them named
DataTransferObjects, but I could be wrong - I don't have it handy.
Generally, DTOs would not be business objects.

>From Sun's blueprints - 
TransferObject: A transfer object is a serializable class that groups
related attributes, forming a composite value. This class is used as the
return type of a remote business method. Clients receive instances of this
class by calling coarse-grained business methods, and then locally access
the fine-grained values within the transfer object. Fetching multiple values
in one server roundtrip decreases network traffic and minimizes latency and
server resource usage.

The Data Access Object (or DAO) pattern: separates a data resource's client
interface from its data access mechanisms. Adapts a specific data resource's
access API to a generic client interface. The DAO pattern allows data access
mechanisms to change independently of the code that uses the data.

Note: The blueprint shows shows a couple of possible implementations. One
shows DAOs populating TransferObjects, another shows DAOs populating
BusinessObjects.


Second question:
We use a BetwixtGenerator to convert the DTO into XML. That XML, aggregated
with other data, gets turned into the forms.

If you are not using J2EE (i.e. EJBs) you can see from the description above
that there is very little reason for TransferObjects. However, in my
opinion, they are still a good idea as they allow you to convert your
application to a multi-tiered system at a later time with minimal impact.

Ralph



-----Original Message-----
From: Danny Bols [mailto:dbols@osirion.be] 
Sent: Thursday, May 06, 2004 9:51 PM
To: users@cocoon.apache.org
Subject: RE: Business Objects vs Data Objects [was Re: JXTemplates - what' s
in a name?]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org