Object-Relational Mapping tools are the must-have features of rapid application development today. They provide an interface to the programmer to write the DB schema and query it using a programming language that he/she knows. They are the adapters in between the programming style and the declarative style of SQL. I am sure they are helpful in the beginning, because you can be quick with them. But does it hold true when your software gets some years old? Is the ORM still helpful?
ORM do have their benefits, but they bring in possible problems as well that we need to be aware of.
- One of the trends I have noticed is that because ORM tools can generate SQL, the team does not include one. Designing the SQL schema and its queries is as important as programming for any application. In some cases it might be more significant. However, this activity gets completely omitted and SQL schema is designed solely on the basis of object model design. The DB schema does not get an independent look. Some years later, when the DB gets highlighted as a bottleneck, the same project managers start a frantic search for a DB consultant.
- ORM, that is supposed to remove the impedance mismatch between the object and relational world, and that cannot be simple to understand. However, ease is considered to be a feature, and we, the programmers, do not give enough time to understand them. This leads to a patchy approach towards using them, and hence the DB schema and queries. Often, refactoring the code to use the ORM in right way leads to changes in schema and queries, which again requires skills of a DB expert.
- ORMs nowadays allow us to execute raw SQL statements as well. It is to be used whenever the ORM API falls insufficient for the our data manipulation. However, this has become an escape route for many. Instead of trying to learn the ORM API, they bypass the ORM altogether by using these everywhere. This also leads to an abuse of other patterns like MVC. You see raw SQL statements being executed in the controllers, reducing models to dumb classes with just getters and setters.
- Though ORMs are evolving, one table per class or one class per table syndrome is still popular. In relational model, one-to-many or many-to-many relationships between two entities typically involves three tables. One for each entity, and one more which represents the relationship. Unfortunately, many ORMs treat this relationship as an entity causing confusion. The confusion increases when one wants to have a many relationship with self. In such cases ORMs highlight the impedance mismatch instead of minimizing it.
- I feel that any programmer who is dealing with an ORM has to understand the relational model being developed. I do not think ORMs are there to shield the programmer from DBs, they are there to help you extend your object modelling in to the relational domain. Though SQL syntax is not a must to work, understanding the underlying concepts of transactions and referential integrity cannot be skipped. Unfortunately, this is not popular with programmers. One side-effect of this also that sometimes ORMs get pitched against some DB capabilities like stored procedures.
Data is one of the most important pieces of our solutions. And so is data modelling and data integrity. I am sure that ORMs were introduced to further this cause and make it easier for us to focus on data. Unfortunately they seem to be doing the exact opposite, not because of themselves, but because of us, the programmers.