Rod Johnson and Jim Clark discuss how the combination of TopLink and Spring's DAO layer offers a high-performance, productive approach to persisting plain old Java objects (POJOs).

This approach is an alternative to the traditional J2EE object persistence solution—EJB 2.x entity beans—which has proven disappointing in practice for many reasons, including a cumbersome programming model, poor developer productivity, and poor testability.

Your persistence strategy not only can determine an application's performance, but can have a huge influence on the effort required to develop and maintain the application—and unless you make the right design decisions up front, it may be hard to revisit this part of the design after the application is finished.

Used appropriately, ORM can slash development effort, and improve maintainability. It is not unusual to see a saving of 30-50% in the amount of Java code that needs to be written by adopting an ORM solution, rather than JDBC.

.....
If you're a TopLink user, you will appreciate the simplification and consistency that this can bring to your coding. Yet, you won't need to sacrifice any of the power of TopLink. If you've a Spring user, you have gained the choice of TopLink for your O-R mapping requirements

Read article Of Persistence and POJOs: Bridging the Object & Relational World

-
Sudhakar
Oracle Technology Network

Used appropriately, ORM can slash development effort, and improve maintainability. It is not unusual to see a saving of 30-50% in the amount of Java code that needs to be written by adopting an ORM solution, rather than JDBC.

This is quite true. However, it is also worth noting that used appropriately, a code generator will generate all of your ORM or JDBC code for you in a few seconds, seeing a saving of 90-100% of hand-written code.

I posted to my blog about Java Persistence Strategies yesterday, where I discuss this in more detail.

Andy Grove
CTO, CodeFutures Software

I posted to my blog about Java Persistence Strategies yesterday, where I discuss this in more detail.Andy GroveCTO, CodeFutures Software

There is an incorrect labelling of technologies in that entry, I think. You make a distinction between 'standard' (JDO, EJB) and 'open source' (Hibernate etc.) products, and 'commercial' (TopLink etc.).

There are plenty of 'open source' 'standard' products (JPOX, JBoss) (and, of course, plenty of 'standard' 'commercial' products). I would have thought a better strategy would have been a simple distinction between 'standard' and 'non-standard'.

Imagine that, first two posts on this thread are a shameless shill followed quickly by a post from the JDO camp.

Fact is, you have misunderstood the difference between a "Specification" and a "Standard". JDO is a "Specification", it's no standard. I wrote about this last year here.

 - Don

Imagine that, first two posts on this thread are a shameless shill followed quickly by a post from the JDO camp.Fact is, you have misunderstood the difference between a "Specification" and a "Standard". JDO is a "Specification", it's no standard. I wrote about this last year here. - Don

Yes, and JDO is regularly, widely used and adopted (just ask the tens of thousands (at least) of developers who use it), as you require for the use of 'standard'. It is certainly not the widest used API for persistence, but that has never been the way the term 'standard' is used (at least, not without the addition of 'de facto'). A specification is a proposal. A standard is a specification that is agreed on by multiple organisations and vendors. By your definition, X-Windows is a specification and the MS Windows API is a standard. Of course, being a standard has no bearing on the the quality (or otherwise) of JDO as an API.

JDO is a "Specification", it's no standard.

Here is someone saying that JDO is dead:
http://www.people4objects.org/Carl/2005/01/jdo-is-dead-rip.html

What do you think of that? Would that mean that JDO is not only not a standard, it's not even a specification any longer?

What do you think of that?

I think Carl will be eating his words after the next JCP vote. But isn't this thread intended to be about Spring and TopLink?

Don, actually I think I won it. My bet was on your 'standards vs specifications' post being among the first five ;->

On a more serious note, are the folks at http://www.iso.org aware of your blog entry? Will they rebrand soon?

Kind regards,
Oliver

Ha. There you go, rubbish.
Toplink, Hibernate and CMP are all useless, terrible additions to the gloop that obfuscates the greatness of java.

Defend myself? Explain myself?

No one but those with a product read this much these days.

I worked with TopLink - admittedly a bad use of toplink, but none the less I hated it. Loads of complexity just to save typing or code gen. And only one or two people bother to understand units of work and the session cache.

I've used Hibernate and have much the same to say.

Simple question here: If you were writting a reporting tool on a large dataset where there are many cross table joins would you stay with objects which map broadly to the tables. Or would you design for speed?

Most 'architects' with mantra's would not design for speed. Because they are fools. And ORM like Hibernate and TopLink seem to encourage foolish thought. And it annoys me.

Jonathan
EmeraldJB - DAO, simple, future proof, and green

Simple question here: If you were writting a reporting tool on a large dataset where there are many cross table joins would you stay with objects which map broadly to the tables. Or would you design for speed?

No wonder why you seem to hate ORM tools, they are not recommended for this type of use. It's like using a hammer to drive a screw: don't blame the tool, blame the person who chose the wrong tool for the job.

Regards,
Henrique Steckelberg

They bring higher performance and more flexibility in using the power of SQL to the table and are far mor easier to use.

They bring higher performance and more flexibility in using the power of SQL to the table and are far mor easier to use.

But POJOs are not supported, only JavaBeans.

I quote the article:

Such technologies as these are capable of persisting genuinely object-oriented domain models...

No they are not. Genuinely OO models do not need a "service layer" separate from a "data layer" (DAO).

They are often said to deliver transparent persistence—the ability for an object-relational mapping product to directly manipulate (using an object programming language) data stored in a relational database.

That is absolutely not the definition of "transparent" persistence. Even JDBC fits that definition!

A product can claim to provide "transparent persistence" when it requires no change and imposes no restriction to one's POJO classes.

Requiring this:

- Finders for retrieving persistent object instances.
- Save methods, for persisting new objects.
- Delete methods, for deleting persistent objects from the database.
- Aggregate function methods for counts or other aggregate functions.

is absolutely not transparent.

The definition of POJO is: "a normal Java object that is not a JavaBean, an EntityBean, a SessionBean, etc., and does not serve any other special role or implement any special interfaces of any of the Java frameworks (EJB, JDBC, DAO, JDO, etc...)." http://c2.com/cgi/wiki?PlainOldJavaObject

I see a tendency of people fudging that definition of POJO because their products obviously do not support transparent POJO persistence.

ORMs such as Hibernate, Castor and Toplink are central players in this depressing context of ours. On the one hand, they provide a palliative in the absence of true OO but, on the other, they actually hamper the community by illuding it and giving OO a bad name.

I sincerely hope the authors' deceit is out of sheer ignorance and non-intentional.

Klaus Wuestefeld
"Objects are here to stay" http://www.db4o.com
"Persistence is Futile" http://www.prevayler.org

I love the sig :)

Jonathan

You miss my point.

It's obviously wrong to use ORM for a reporting system, where the speed of reports is often focused at one or two indiviual (important) users.

However, the ORM mantra encourages people to hide the database and its optimisations. All the ORM verdors now have caviats - use sql, or our custom sql, or a sproc, or arm waving if you need speed of selects.

But this is simply highlighting a serious flaw in the entire design. Fine, I agree CommandBuilders, or insert/update generators are great, I prefer compile time rather than runtime. But such things do not need ORM products, with XML configs all over the place.

Database is where the data is, objects are where your applications logic resides. The join between the two should be appropriate (fast, reusable etc). There should be no single layer or view on how to use the data in the database. Different apps need to use it in different ways. But most users of these products take an all or leave approach - my way or the high way.

A particular nasty is the polymorphic mapping of objects to underlying tables which tends to add complexity, maintenance issues and confusion to those who follow. The gain being that its the 'correct' way of doing ORM.

Jonathan

You miss my point.It's obviously wrong to use ORM for a reporting system, where the speed of reports is often focused at one or two indiviual (important) users.However, the ORM mantra encourages people to hide the database and its optimisations.

All of your arguments could applied against the use Java:

"The VM mantra encourages people to hide the machine code and its optimisations. All the VM vendors now have caveats - use C/JNI if you need speed of machine code... But this is simply highlighting a serious flaw in the entire design ... I prefer compile time rather than runtime." And so on.

Why do we use Java? Not because it is the fastest or most optimised technology, but because of the tremendous advantages of portability and vendor independence. Of course ORMs hide the database and its optimisations. That is the point. But, as with Java, hiding the optimisations does not mean they are not used. ORMs allow the use of native SQL if necessary, just as Java provides JNI, but that should not mean we abandon the advantages of portability for all the code.

I do not think this kind of analogy can help to understand ORM. Probably SAX vs DOM is a better analogy.

I do not think this kind of analogy can help to understand ORM. Probably SAX vs DOM is a better analogy.

Could you explain this? Neither SAX nor DOM abstracts away from the underlying technology (XML).

Both parsers can "abstract" from text file parsing. All analogies are silly, but this analogy is about data structures. POJO persistence asumes your data structures are POJO (probably transformied or proxied). JDBC has no asumptions about application data structures and can be used (and is used) to implement POJO persistence. SAX Handler is used in similar way to build DOM tree. So JDBC is more "abstract", because it has less asumptions about use case, but it doe's not mean "abstract" is "better".

Both parsers can "abstract" from text file parsing. All analogies are silly, but this analogy is about data structures. POJO persistence asumes your data structures are POJO (probably transformied or proxied). JDBC has no asumptions about application data structures and can be used (and is used) to implement POJO persistence. SAX Handler is used in similar way to build DOM tree. So JDBC is more "abstract", because it has less asumptions about use case, but it doe's not mean "abstract" is "better".

SAX is rarely used to build DOM trees. SAX is an event-driven way of processing XML. DOM is a way of representing an XML document as an object tree. The two APIs are very hardly ever used together.

Of course, JDBC is not more abstract. It is at a lower level. For example, Java has a huge network API. This allows developers to handle network connections and sockets at a low level. If a higher level of abstraction is required, then developers can use APIs for protocols such as http. Would you say that the raw network API was 'more abstract because it has less assumptions about use case'?

POJO persistence does not assume what you think it does. It is a mapping between Java objects and structures in the underlying stores. It makes no more or less assumptions than the store, and it has no implications for use case. It is simply an abbreviation. Instead of using verbose and store-specific JDBC calls you simply access bean properties, which is surely a more natural way for a Java coder to develop.

JDBC does, of course, make assumptions about the structures of the data! If you call recordSet.getLong("fieldName") that call won't work unless you understand the structure of the data....

I think it is better to abstract domain and JAVA "standards" than underlying stores. All usefull underlying stores support the same SQL interface, API calls can be generated to abstract different POJO persetence standards.

All usefull underlying stores support the same SQL interface,

This is, of course, obviously not true. If it were true then ORM would be a lot easier to write. In reality, each ORM product has to put a lot of work into dealing with the considerable differences between the SQL interfaces of different stores. It is very hard, perhaps impossible, to come up with high-performance common SQL that runs on MySQL 4.0, PostgreSQL, Oracle and SQL Server. ORM allows you to make the best of each store as it generates optimised SQL for that store.

Right driver "abstracts" dialects too, but you need wokarounds for broken drivers in practice,
it is more trivial than it sounds:
http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate2/src/net/sf/hibernate/dialect/PostgreSQLDialect.java?rev=1.21&view=markup

I do not think it is a good idea to use ORM as workaround for broken software abstraction. ORM has more usefull features like cache and model transformation (it makes sence in some cases).

Right driver "abstracts" dialects too,

Repeating the point yet again: The JDBC driver provides a subset of features. ORM can provide a superset.

but you need wokarounds for broken drivers in practice

Yes, but why should I have to do that? Let the ORM people do it.

I do not think it is a good idea to use ORM as workaround for broken software abstraction.

You have to work around the problems with SQL dialects anyway. It makes sense to let someone else do the work.

Driver developers need to care about it, ORM doe's it in practice, but I think it must be more intersting things to discuss about ORM. I think mapping patterns and antipatterns need more discussion.

What do you mean?

What do you mean?

I mean thinking by analogy is wrong.

OK, so we've now got two camps here:

* the ones who don't believe in ORM, thinking that it hides too much of the relational database (recommending traditional DAOs based on JDBC and SQL instead)

* and the ones who want to get rid of the relational database altogether, working with "pure objects" and considering everything else as deceit

Both agree that they don't like ORM, but for completely different reasons. Consequently, they need to hate each other's point of view more than ORM, because it differs even more from their own point of view than ORM...

Anyone interested in discussing the actual topic of this thread instead: Spring/TopLink integration?

Juergen