Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Mime-Version: 1.0 (Apple Message framework v613)
In-Reply-To: <s09a0917.096@cs-emo.csir.co.za>
References: <s09a0917.096@cs-emo.csir.co.za>
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <F7BAFDA6-9F77-11D8-A4AC-000A95AF004E@apache.org>
Content-Transfer-Encoding: quoted-printable
From: Bertrand Delacretaz <bdelacretaz@apache.org>
Subject: Re: Business Objects vs Data Objects [was Re: JXTemplates - what's in
 a name?]
Date: Thu, 6 May 2004 18:11:01 +0200
To: users@cocoon.apache.org


Le 6 mai 04, =E0 09:44, Derek Hohls a =E9crit :

> Bertand
>
> Is there not a difference between a Java "business
> object" (which I assume in a Cocoon app will be a
> POJO - even though I do not now know where and
> how to create this...) and "data access object" - at
> least that what the Core J2EE patterns imply
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/=20
> DataAccessObject.html

To be strict, yes: a DAO's role would be to interface with a database, =20=

save and retrieve data, that's it.

Whereas a "business object" usually means an object that sits on top of =20=

DAOs (or other data access methods) and implements business rules, =20
aggregations, etc.

But I think this is not terribly important when talking about how to =20
interface Cocoon with Java objects.

Basically, if you're using Flow as a front-end to business logic and/or =20=

data access stuff written in java, the Flow needs to:

1) Access the java objects
2) tell them to load the required data
3) manipulate the data (maybe with CForms) - the java objects are most =20=

often not used for this step
4) tell the java objects to save the modified data

That's it, and this is demonstrated (although in a very simple and =20
limited way) by the bean editor app in the supersonic block.

The objects shown there do not use a database, the data is just being =20=

held in memory. But adding database load/save would happen only in the =20=

java world, without requiring further interaction with Flow (other than =20=

Flow calling the load/save methods at the right times).

Also, this example app uses a simple instantiation for 1), but if you =20=

really make your java objects play with the Cocoon framework, you'd =20
want to use the Avalon object lookup mechanisms for this. It's a bit =20
more complicated but not that much.

Hope this helps!

-Bertrand


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