Re: Persistence, EJBs and OO-Relational mapping

<sriniv79_at_my-deja.com> wrote in message news:90m65j$q28$1_at_nnrp1.deja.com...
> I read many articles on persistence recently, but all of them leave me
> more confused than I intitially was.
>
> 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.

> As every one here knows, a well designed relational data model is more
> than the data itself. The relational tables are managed with
> referential integrity rules, triggers and constraints. Above all, the
> relational data posesses rigorous relational arithmatic properties
> like "orthogonality" and "closure".
>
> 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.

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

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

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

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

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 :-) Received on Sat Dec 09 2000 - 09:15:05 CET