Design Philosophy

• Getting the Job done
• OODBMS versus ORM / RDBMS
• ORM is good but Relational is sometimes Better!
• Ebean's Relational features

Getting the Job done

A simple and robust persistence layer that gets the job done. Ebean is not trying to take a 'purist' or moral 'high ground' but it is trying to keep things as simple and as clear for the developers who use it.

OODBMS versus ORM / RDBMS

In choosing an ORM you have likely chosen an RDBMS over an OODBMS (or already have an RDBMS). If you have not had time to investigate this decision you perhaps could spend some time on this.

There is a view by some (CJ Date included) that the only thing OO brings to the Relational model is Type Inheritance. There is also the debate about what functions should be handled by "Data Management Systems" versus "Application Code".

« ORM's "Ugly Duckling" - Inheritance »

I think it is fair to say that the "Ugly Duckling" of ORM is the way Inheritance is implemented. Specifically the DB Design and SQL used in handling inheritance could be considered a bit ugly and convoluted. From a RDBMS perspective the SQL and Design required could sometimes be described as a little 'forced'.

As RDBMS vendors include SQL3 Type Inheritance (Oracle, Virtuoso, Postgres) then this "Ugly Duckling" should disappear as the SQL and Design for handling Inheritance would become more 'natural' to the DBMS and not 'forced'.

There is the potential for ORM and RDBMS to provide the best of both worlds. The benefits of Relational Database Management Systems with a natural approach for Object Orientated Development.

ORM is good but Relational is sometimes Better!

Don't get me wrong - ORM is great - but I believe it is a trap to think ORM is always the best solution. Specifically for ad hoc queries and updates and deletes in a stateless environment Relational approaches can be simpler to use and more efficient.

I have seen a number of ORM Vendor code examples where an Object is fetched back from the database just so that it can be updated or deleted. In doing so there is an additional query against the database and the code bypassed any Optimistic Concurrency Checking. This would be fine for an enterprise with a very small 'e' - but I'd suggest its a pretty poor approach.

For stateless web applications you may not have all the information required for a bean. The bean may have 20 properties and you only have 5 of those coming back from the HTML FORM. You also do not have the original bean for either updating or deleting. In this case you will likely find a more relational approach easier and more efficient.

Refer: ORM Updates and Deletes in a Stateless environment

EJB QL for Reporting or Ad Hoc?

Many queries in a system are for Reporting or Ad Hoc in nature. The results of these queries are often read only and not intended for updating. Often I think these types of queries are better left as naturally relational rather than forcing them into say EJB QL and specific Objects. Ebean does not currently support EJB QL so perhaps this is blatant bias :)

Ebean's Relational features

The goal of Ebean is not to hide the Relational Database. More than that the goal of Ebean is to promote the use of Relational features when they make most sense. The use of UpdateSql, CallableSql, FindByNative and MapBeans will sometimes provide a simpler and more efficient solution that an ORM/Bean solution.

It is the intention for Ebean to provide both ORM and Relational features in the one persistence layer. This gives the developers the ability to choose the approach that best solves their needs. Whats more these features are all designed to work together in the same transaction.

Whether you use these features is up to you but hopefully you find them a useful way to get the job done in a simple and transparent fashion.

Next: Limitations of Ebean