How does ORM work under the covers? Also what is the best way to have persistent objects in Java?

Question

How does ORM work? Are objects serialized into BLOBs?

In Java, is JDO still the way to go for this? What else is available? Seems like there was a lot of talk of EJB, direct object serialization, and JDO.

Answer 1

ORM = Object Relational Mapping, attributes of the objects are mapped to columns in the realational database. That mapping is arbitrary, so that could be done to blobs, in practise what is most useful tends to natural mappings - Strings to Varchars, int to integers etc.

JPA is the place to look for a standard for ORM. JPA replaces the EJB CMP approach, which was found to be cumbersome. JPA allows you to express the mapping as Java annotations and also allows the mappings to be specified in configutration files, when supporting multip[le databases the latter can be useful.

JPA has a query language so that you can construct queries against object attributes.

JPA is supported by the major App Server vendors and also by products such as Hibernate.

I found JPA pretty nice to work with, more so than EJB CMP.

I would recommend still using EJB Session Beans facades for transaction mamangement and security - the annotation-based approach makes EJB 3 way easier to use than EJB 2, minimal coding overhead.

Answer 2

JDO is actually standard ORM too, and provides a more complete a specification than JPA (1 + 2). JPQL is more focussed on RDBMS concepts and hence mimics SQL. JDOQL follows Java syntax so is more object based. Depends if your app is ever considered to go away from RDBMS. If so then JPA is not the way to go. If it is solely for RDBMS then JPA is definitely a consideration.

Whether objects are serialized into BLOBs depends on your configuration. You can do that for complex object types if you wish, but then they won't be queryable. If you instead persist them in a native form then you can also query them, leading to more efficient apps.

--Andy (DataNucleus - JDO and JPA persistence)

Answer 3

To answer your first question, here is an extract from Hibernate in Action, that says that there are various ways to implement ORM:

Pure relational

The whole application, including the user interface, is designed around the rela- tional model and SQL-based relational operations. This approach, despite its defi- ciencies for large systems, can be an excellent solution for simple applications where a low level of code reuse is tolerable. Direct SQL can be fine-tuned in every aspect, but the drawbacks, such as lack of portability and maintainability, are sig- nificant, especially in the long run. Applications in this category often make heavy use of stored procedures, shifting some of the work out of the business layer and into the database.

Light object mapping

Entities are represented as classes that are mapped manually to the relational tables. Hand-coded SQL/JDBC is hidden from the business logic using well- known design patterns. This approach is extremely widespread and is successful for applications with a small number of entities, or applications with generic, metadata-driven data models. Stored procedures might have a place in this kind of application.

Medium object mapping

The application is designed around an object model. SQL is generated at build time using a code generation tool, or at runtime by framework code. Associations between objects are supported by the persistence mechanism, and queries may be specified using an object-oriented expression language. Objects are cached by the persistence layer. A great many ORM products and homegrown persistence layers support at least this level of functionality. It’s well suited to medium-sized applica- tions with some complex transactions, particularly when portability between different database products is important. These applications usually don’t use stored procedures.

Full object mapping

Full object mapping supports sophisticated object modeling: composition, inher- itance, polymorphism, and “persistence by reachability.” The persistence layer implements transparent persistence; persistent classes do not inherit any special base class or have to implement a special interface. Efficient fetching strategies (lazy and eager fetching) and caching strategies are implemented transparently to the application. This level of functionality can hardly be achieved by a homegrown persistence layer—it’s equivalent to months or years of development time. A num- ber of commercial and open source Java ORM tools have achieved this level of quality. This level meets the definition of ORM we’re using in this book. Let’s look at the problems we expect to be solved by a tool that achieves full object mapping.