OpenORM is unique in that it fits right in the middle of other frameworks that either try to do too much, or too little.

3/30/2011 - Released OpenORM .7 with the new API syntax changes. Everything is backwards compatible so you can upgrade as you get time.

11/28/2011 - Released OpenORM .8. The column can now take a (new) Value object. The Value interface is a callback so that the retrieval of the value for a given column is delayed until a writer (insert, update, delete) needs it. The Value interface has also proven to be flexiblable enough that it is encouraged to use it in place of the Sequencer.

This is what OpenORM believes:

Selecting Data

• Writing your own select statements is good.
• Relating the select statement results to your domain objects is also good.
• Mapping those domain objects into the object graph is what the ORM should be doing.

Persisting Data

• Proxing domain objects is not worth the hassles that come with it.
• Annotating ORM at the class level is inflexible and verbose.
• Configuring ORM in XML is flexible but error prone and verbose.
• Your database should not have to match the domain objects.
• Mapping the domain objects should be done in straight Java code.
• Mapping the domain at the object level is easier, less error prone and more declarative.
• Walking the object graph and creating insert, update and delete statements is what the ORM should be doing.

OpenORM came out of years of frustration with working with other ORM frameworks that claimed to be unobtrusive and transparent to work with, but in reality were quite the opposite. For my projects I wanted an ORM solution that was easy and fun to work with, but would still do all the heavy lifting that ORM is supposed to provide.

So how is OpenORM different?

• OpenORM reminds us that at the end of the day what ORM is really doing, for most projects, is generating SQL statements that get run in the database.

• OpenORM takes the burden of navigating the object graph for you, and either puts the graph together (selects) or maps the graph to the database (inserts, updates, and deletes). But that is all it wants to do.

• OpenORM wants to stay out of your way as much as possible. So instead of using Annotations or XML to map the relationships, it uses straight Java code. There is no proxing involved and it does not care what kind of data types you use.

• OpenORM maps everything at the object level, not on the class. The class knows of the type, but the object knows of the type and the value. Plus the object knows how to deal with the relationships. What I came to realize is that the reason other frameworks have so much configuration is because they have to tell the class how objects will be related to the database, when in fact the object knows exactly how things are related.

• OpenORM believes that complex relationship mappings should be easy and consistent, and in fact you can map any kind of relationship with one clear syntax.

• OpenORM will generate the insert, update and delete statements for you in the correct order. It is up to you to run them.

• OpenORM believes that error handling is very important. It checks for everything it can and will throw a very clear exception when something is configured wrong.

For more information you can read about mapping select statements to retrieve your objects, and about mapping your objects to handle the inserts, updates and deletes. I also recently used OpenORM to work on a pure CRUD application and wrote up a page to describe how that went.

If you have any questions be sure to post them to the groups or you can email me directly at jeff.johnston.mn@gmail.com.

In Other News...

Here are a few other frameworks and tools that I have developed.

JMesa

• A dynamic HTML table that makes working with tabular data in your web application a breeze.

Configleon

• A Spring tool that solves the problem of loading property attributes in different environments and/or server contexts. With Configleon you can build one war file that can be deployed to every location.

Alertleon

• An alert system that is tightly integrated with Configleon and offers an advanced way to trigger email events in your application.

CodeSlayer

• A source code editor that boasts a clean interface but powerful features. It is written in C using the GTK+ toolkit.