Re: Persistance Layer wanted!

"Manfred Pruntsch" <manfred.pruntsch_at_ifcos.com> wrote

> I'm looking for a persistance layer to bridge a java application with oracle
> in a object relational way. I didn't find anything on oracle's website. So I
> asking for experiences and recommendations for stable applications. Links to
> reviews, articles treating this stuff are also welcome.

Well, within Oracle a persistant object basically is the physical row in a table - or a relationship that describes (joins) or or more rows.

Which can be described with a UDT with properties, constructors and member methods - in Oracle.

> We use Oracle 9.2/Java 1.4.
> Some requirements:
> - Transaction

Standard and best practise Oracle transaction methods apply. Don't treat that differently because of an OO design.

> - Object identity

Explain. (duplicating refenrential integrity and relationship in an OO class hierachy when it is *already* done in Oracle is just plain stupid)

> - Relative independent from business layer

That is achievable even without OO. It all depends on how you select to implement it.

• do you provide a PL/SQL API to read, write & change table rows? (instead of a manual SQL SELECT, an API call is used to retrieve the data - business logic resides at caller's side)
• do you provide a business PL/SQL API to perform business processing on Oracle tables and rows? (business logic, or big portions of it, now resides in PL/SQL)
• do you wrap Oracle tables with UDT and OO interfaces? (and as above, do you do this at basic data access level or at business access level?)

I personally see no advantage in having the business layer outside Oracle. The only exception being an ISV and developing for a variety of db platforms.

What really gets me swinging my lead pipe is that the *fundemental* concept of an object is encapsulation.. and yet the Java dudes want to create the object outside Oracle instead of making it *part* of the data INSIDE Oracle. And yeah it can be done - no Java required.

And maybe that is exactly the problem. It just rubs the Java dudes the wrong way that it can be done better and faster and more secure without using The Holy Language.

> - Handling a bigger amount of objects

In Oracle I can create a cursor that holds any number of rows. I can make it a reference cursor (PL/SQL function call) and pass the handle to the client so it can go trolling through a billion rows. (good luck with that - and don't call me for snapshot too old and rollback size problems)

However, the first question is WHY. Doing something like that only displays a severe lack of ignorance about db processing.

The second question is also WHY. Why do this when the data (i.e. objects) ALREADY persist in Oracle as rows? Why construct them again in the business tier? (answer: piss poor architecture choice, bad OO class design and poor OO implementation)

> - Stable for production environment

That depends on how savvy you put into your Oracle config. Treat it like it's MS Access and you're in for a rude awakening.

> - Good understandable API...

You define the API. How good and understable that is, is directly related to your design and coding of said API.

If I seem a bit crass Manfred, it is because I have seen Oracle being treated like a silly persistant object repository where none of Oracle's features and advantages are needed, resulting in poor performance, wasting money and frustrating the hell out of the DBA. And dealing with a pissed off DBA is sure to ruin your day.. ;-)

--
Billy