cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Hohls" <DHo...@csir.co.za>
Subject Re: Business Objects vs Data Objects [was Re: JXTemplates - what'sin a name?]
Date Fri, 07 May 2004 10:36:43 GMT
Here is another thought (not mine - 'scuse the blunt language!)
on "DAO design pattern isn't" from the thread:
http://www.theserverside.com/news/thread.tss?thread_id=25695#120732

Jochen Bedersdorfer says:

"I designed a little sub-project using the DAO design pattern to make
it independent from the persistence technology. WHAT A WASTE OF TIME!
You are writing class after class just plumbing things together, after
that
your business code looks like a one big mess.

In annother project we used CMP. Holy moses, why do I have to seperate
my 
business  logic/application logic when the only logical place is in the
damn CMP beans?
All this nonsense about putting your logic in statless session beans,
opening up
your persistent beans with numerous public setters/getters is breaking
all rules about a clean, encapsulated and simply OO design!
Every public method you have is one your developers will screw around
with.

Then I tried JDO and the world was fine again! I could reduce the
number of 
public methods significantly, putting all user-editable data in more or
less
generic DTO-objects, leaving the business logic right in the classes I
would
use for persistence, reducing the lines of code significantly.
Now our sessions beans rarely do more than getting a persistent object
by
Id and calling a business method right inside there and it is working
wonderfully.

Changes to the system are wonderfully localized (no traveling through n
tiers
just to add an attribute to a class) and performance is good. "

I understand this he means that there are:
* objecst to access that data [in JDO]
* objects to encapsulate business logic
and that's all...

Is this not a practical and useful approach that would work in most
cases?

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


Mime
View raw message