What is this ORM pattern called

Question

I have been used to frameworks like JPA to do the object-relational mapping between database rows and Java objects.

However, in my company we use proprietary framework for ORM, which doesn't use entity classes to represent an entity but just a java.util.Map class with database column values mapped to their names.

Typically such a map works also as a model for the presentation tier to render the form. Posting the form again injects the parameters to the handler methods as a map. It is an old framework from early 2000's.

Even thought the use of maps over entity classes smells like obsolescent and an anti pattern, I actually like the "dynamic" nature of this model. You can easily add any data to the map in the business logic layer before map gets passed to the presentation tier, and it becomes part of the form with only changes to the template itself. It allows you to augment any entity with anything, if necessary. And this is ultimately useful, if you must for example show certain notification for a certain field under certain conditions. You just check the condition, add the notification to map if necessary, and in template render it if it exists in the map. If I used entity classes, I would have needed to refactor the entity class interface with an attribute, which is not even real attribute of the entity. The business logic is full of these special conditions and they are constantly evolving.

Is this dangerous thinking - am I falling for an anti pattern? Or is it justified to use this kind of pattern with complex business domains, and does this pattern have a name?

Answer 1

I don't know a pattern that would fit your description, but using Map s over entity classes also has disadvantages.

You can easily add any data to the map in the business logic layer before map gets passed to the presentation tier, and it becomes part of the form with only changes to the template itself.

What you see as an advantage means that you can never be sure in which state the Map is. If you load an entity through service 1 the map might contains some values. If you load the same entity through another service 2 it might not contains some values. The state of the Map is use case specific.

Since you are using a Map it also means that from a client's perspective each property has the same type, eg Map<String, Object> . So if you see an entity map in your code you also have to know which type it has. Without knowing that it would be hard eg to calculate an orders total.

As long as you are the only one that works on the code and you know all Map states you will think that it is flexible and fast. If you haven't worked on such code for some time you might forget the different states that the Map can have. You have then to go through the whole code for each use case to see if some piece of code adds or removes properties or just replaces the properties type.

So try to think of that design from a documentation perspective. The big advantage of a dedicated entity class is that it is named. You can give a class a name and therefore a meaning. Eg

public class PlacedOrder { ... }
public class Refund { ... }

You can also easily add javadoc to the class to give a bit more detailed information of what this class means in your context. This is usually called the Ubiquitous Language . I often just use the term domain language, because it's easier to speak.

In my experience such design often lead to a hard to maintain system. At the beginning when the code base is small you are really fast. But this is not amazing, because you often save documentation time by not applying clean code principles.

Since types can't be checked by the compiler you will find type problems only at runtime. This means that you must create a big test harness , because the tests must also uncover the bugs that otherwise a compiler would report. Or you just develop the trial and error way, but this is not my way and does not satisfy me.