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

[Derek Hohls <DH...@csir.co.za>]

Ugo

I thought I understood this, but now....  
is not the point made by this article that one can
have "business logic  coded in the classes persisted by JDO...
to encapsulate the model of the application"
- why do we need DAOs and Service Objects as well ?? does
this not just add complexity for the sake of it?  

Derek 

>>> u.cei@cbim.it 2004/05/07 12:15:48 PM >>>
Derek Hohls wrote:
> I just found an interesting quote from a paper on JDO:
> http://www.jdocentral.com/pdf/eigner_jdo.pdf 
> 
> "With the availability of JDO, it makes you wonder when 
> and if you would ever need an EJB container at all within your 
> application architecture if you use it only as a front-end 
> to your database. All the model-oriented business logic can be
>  coded in the classes persisted by JDO, sparing us from using 
> patterns such as 'data object' or 'value object'. 
> After using JDO we contend that most web-based applications 
> could be developed more easily with a web container and a set 
> of JDO enhanced classes to encapsulate the model 
> of the application. "
> 
> This sounds very attractive to me from a learning POV for
> a standard DB application:
> * use flow for the controller; interactiing with forms and
> * enhanced JDO for the model/data access
> * views by generator of your choice...

Yes, this is the promise made by all the ORM tools like JDO and 
Hibernate. This, however, does not obviate the need for:

- DAOs, unless you want to mix your data access logic with your 
controller or business logic
- Facades (or Service objects, if you like) to encapsulate logic
dealing 
with handling multiple data objects at once, possibly within the span
of 
a single transaction.

In the end, it depends on how much complex your use case is.

	Ugo


---------------------------------------------------------------------
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