Re: Persistence, EJBs and OO-Relational mapping

Thank you for a very illuminating response, Please see my responses inline.

> > First let me state the main issue. What is the rationale behind
 trying
> > to persist "relational data" in the form of "object oriented data"?
>
> Its the other way around. We're trying to persist "object oriented
> data" by piggybacking off the relational tools.

That might be the right thing to do. But I have seen pure relational data, such as Invoice and Line Items, being brought from the RDBMS and persisted in object wrappers!! Do you also agree that this is wrong?

> > At the best, the OO paradigm can only implemet the relationships,
 but
> > may not extend to cover other properties of relational databases
> > mentioned above. Or am I wrong?
>
> The OO paradigm handles all these things but differently, i.e., within
> its *own* paradigm.

I can only take the *own paradigm* with a pinch of salt. I would like my data obey the rules of relational arithmatic whichever paradigm is used to represent it.

>
> > No one has problems with the 3-tier or n-tier application
 architecture
> > models, then, why are we trying to bring the data layer into
 middleware
> > tier?
> Because the OO-Relational bridge has to be made somewhere I guess.
> What exactly are you refering to here?

Why can't we leave the relational data in the RDBMS layer? Why do we need to bring it up a layer higher, and represent tables and relations as objects and associations? Why do we need persistent Java components that are used to persist the data of relational nature? In other words, why do you implement an Invoice as a persistent component?

> > Isn't it too simplistic to ignore the power, flexibility and
> > ubiquity of the RDBMSs?
 

> Yes. However, OO has its own needs and it cannot seamlessly
> piggyback these capabilities. One big issue is writing the app
> with an OO domain but using procedures, since you're splitting
> the logic between two separate systems. This can be hard to
> program and harder to manage. Triggers are a bigger problem.
> If the OO model initiates the change within itself and updates the
> RDBMS, then how does the rest of the OO model pick up the
> cascading changes from the trigger within the RDBMS?

The best that Java could offer to search the associated objects is by accessing the enumeration of the associated objects and loop through them. It lacks the random and conditional access. This violates the fundamental qualities of RDBMS tables - projection (select *) and materialization (col1+col2).

>
> > OO technology is great. Awesome design patterns are direct results
 of
> > this wonderful technology. Concepts like composition, interfaces,
> > serialization, polymorphism etc. are all great. Right way to use
 these
> > techniques is in solving the business processes, business rules and
> > application architecture, but not modeling the data into the middle
> > tier.
>
> Whose middle tier :-? Sorry, but there are different meanings of
 middle
> tier in different realms. Do you mean OO taking over the things that
> RDBMSs do?

I had the J2EE platform in my mind. I am seeing more and more literature, where OO is being suggested as the way to manipulate the relational data (e.g. persistent EJBs). I simply can't understand how can this be good to any application. That is my basic inquest.

>
> > Or am I completely wrong? Can somebody explain me where the
 technology
> > of EJB and OO-Relational mapping are leading us towards?
>
> If one can't say something nice one shouldn't say anything at all, so
> let me only comment on the OO-Relational mapping:) Its only using
> RDBMs as a means to an end, i.e., persist the data and present an
> OO interface to the rest of the application. Its OO driven, period.
 The
> data is public for read-only access via SQL, but it has to be private
> for updating via SQL, because that is in the "backdoor". So the short
> answer is that OO-Relational mapping is leading us towards better OO
> applications and that is all.

Do you suggest that the persistent models are useful only in "readonly"  mode and one must use regular methods like SQL to perfrom the updates? I can agree with that to a very large extent.

But, what about the random access requirements of the data, even in the read-only mode? I can't JOIN objects like I do tables.

>
> The longer answer would be a tool that provided both an OO and a
> relational interface to the data. But since there is no such thing as
> data in OO -- only functionality, this tool will basically subsume the
> entire application logic (overdramatic statement). My 2AM comment
> is that there is something fundamentally incompatible between
> OQL and OO (whew, where did that just come from :-?). OQL has a
> place as an interface, but not as a means of separating data from
> functionality. So the choices are either added syntactical sugar to
> SQL (basically the OO-relational mapping), or moving the application
> into the database itself and providing a relational (SQL) interface to
> it. Perhaps that is where Java procedures will take us :-)

So, is there a case against persistence of relational data in OO paradigm?

-Srini

Sent via Deja.com
http://www.deja.com/ Received on Wed Dec 13 2000 - 19:03:27 CET