Since version 2.0, ABL supports Hibernate's Map entity mode. This mode uses Maps to represent persistent objects, rather than Java beans (also known as POJO's).
The main benefit of this approach is that it gives you great flexibility: since you don't have any hard-coded Pojo's, you can theoretically run against any database schema.
However, there are also downsides to consider:
Even in Map mode, Hibernate still needs to know about your database schema. You will therefore need to create a mapping (typically in XML). However, this is still more flexible than hard-coding your database schema in Java classes.
This is probably the main downside. Using map objects is not as natural as using Pojo's. Because everything is generic, there will be no compile-time checking, so it's easy to mistype the name of an attribute, and you will need to do a lot of casting (unless you use Groovy).
The ABL engine requires no special configuration to use Hibernate's Map mode. It will simply detect that Hibernate is using that mode.
This will of course affect how you define your business logic, because you will not get any Pojo's for CurrentBean and so on. So instead of the standard:
you will have:
Your logic code will then have to access data using this object:
Note that Groovy makes this significantly easier by allowing you to (mostly) ignore types and casting.
One very common problem with the Map mode is that, if you have objects that may, directly or indirectly, reference themselves (i.e. if your object model contains cycles), you may run into a
To understand why this is, consider the following code:
This code will cause a
This is not a problem that is specific to Hibernate: any Java program can exhibit this behavior.
To avoid this issue, ABL provides the method