Thoughts On Hibernate
The main purpose of Hibernate/JPA was to address and solve the Object - Relational impedance problem. Java is an object-oriented language and there is no way but to use classes and methods. So we design and develop our Java applications in the object-oriented way.
Since programmers use and deal with objects, and data resides in tables related by common fields (keys), there is a mismatch. Technically, yes, the way data are laid out in the columns of tables and the way they are used in the application as the class / instance variables there is. So when we see, comprehend and discuss the data on the application side and the database side, there is a difference in the visualization and communication.
However, this mismatch or "impedance" does not come in the way of software development that it requires a framework that abstracts away all the database-related code. It is not rocket science that programmers can't work with rectangularly laid out data. In my opinion application programmers have, and will continue to have fluency, with both classes and tables.
Database concepts and commands are part of the learning curriculum of any software-related course. Engineering / computer science students are taught basic SQL syntax and know how to query databases. So, in a typical case you would NOT have a developer who says that they know only an object-oriented language and will work only with it.
I have seen two more behaviours. When asked to do a design, people invariably end up thinking in terms of rectangularly-laid out relational data. Some how operations and data seem to come comfortably to a lot of people. Thinking only in terms of objects and their relationships seems to come secondary. Even if they start with classes, after some time, the thought process and vocabulary settle around methods and tables.
The second aspect comes with supporting production problems. As programmers gain experience and move into senior roles, they are called into fix urgent problems faced by customers in live environments. The first steps almost always include looking at log files and the database. A lot of analysis centers around database tables and columns to understand the values or the state of the data.
Part of this comes from the fact that the customer-support guys are chasing development teams over emails and phone, some times even standing behind their back, so trying to debug through source code is not done every time as it takes a little bit more time to set up. Dealing with the log file exceptions, database values and Googling around gives quick fixes in a lot of cases.
Thus a programmer gets imbibed with relational structures thoroughly. When the production-support developers become the designers for the next release or the next module, they quickly get into the methods - tables thought process and vocabulary. The so-called object-relational impedance, even if it were existing previously, just disappears over time.
Hence the very premise, the insurmountable object-relational impedance, that led to building ORM frameworks is questionable. That's not the only problem. There started a new set of issues as Hibernate/JPA evolved.
People had to learn a new framework. The very idea of learning another framework seemed to be an additional responsibility, kind of a burden. It involved new APIs, first XML then annotations, and new configurations. In comparison, JDBC just seemed to be a natural part of Java with just seven steps to learn.
From my experience, I recall that Hibernate-based applications consume more hardware resources. In the era of hardware commoditization and 64-bit systems, this is normally not a problem. There are performance problems related to using Hibernate.
Of course, by using performance-improving techniques, we could address them. But then this meant spending time on learning those things, adding Hiberanate/JPa as a training topic for freshers, applying the performance-improving tips as an extra activity and retaining that knowledge within the groups. In the pre-ORM days, if application queries were taking a lot of time, you just moved some action to database procedures.
A lot of business operations and reports involve writing complex queries. Writing them in terms of objects and maintaining them seems to be difficult; it is easier to read and comprehend complex queries in terms of tables. In such cases, people prefer to write native SQL queries just overriding the persistence framework.
This is not to say that there is nothing good at all in Hibernate/JPA. The current thinking around Hibernate seems to be : if your application is primarily a CRUD-drive one, performance is not that critical, and as a development team you have a good say in the database design, you could just go for Hibernate/JPA. It would help achieve your goals in fewer lines of code than JDBC.
There are other benefits too. Lazy initialization patterns are already available in Hibernate, and they are not easy to hand code. Intelligent updates where only the updated fields are included in the SQL reduce network traffic. Since Hibernate is coming up with polyglot persistence, it would be easy to migrate to a NO-SQL database.
Considering the trade-offs, I would think that over a period of time, the development world will move away from Hibernate/JPA. At the moment, there are alternatives in the form of Spring JDBC and jOOQ, amongst others. I have looked at jOOQ briefly.
It reverse-engineers the tables to create java mapping classes and allows you to query the objects in an almost SQL like manner. The generated classes have the same name as the tables, so your Java code "reads" like SQL. I like it.
From the aspects of reducing the learning curve due to decreased boilerplate and annotations, and communicating via table names and SQL queries, jOOQ looks promising. It needs to be explored a bit more by developers. Figure out if it is tackling the unnecessary object - relational impedance problem or unnecessary boiler plate code. If it is just the latter case, then it's in the proper direction.
(Views are completely personal, I don't have any business interests with the makers of the frameworks mentioned in this article).
Since programmers use and deal with objects, and data resides in tables related by common fields (keys), there is a mismatch. Technically, yes, the way data are laid out in the columns of tables and the way they are used in the application as the class / instance variables there is. So when we see, comprehend and discuss the data on the application side and the database side, there is a difference in the visualization and communication.
However, this mismatch or "impedance" does not come in the way of software development that it requires a framework that abstracts away all the database-related code. It is not rocket science that programmers can't work with rectangularly laid out data. In my opinion application programmers have, and will continue to have fluency, with both classes and tables.
Database concepts and commands are part of the learning curriculum of any software-related course. Engineering / computer science students are taught basic SQL syntax and know how to query databases. So, in a typical case you would NOT have a developer who says that they know only an object-oriented language and will work only with it.
I have seen two more behaviours. When asked to do a design, people invariably end up thinking in terms of rectangularly-laid out relational data. Some how operations and data seem to come comfortably to a lot of people. Thinking only in terms of objects and their relationships seems to come secondary. Even if they start with classes, after some time, the thought process and vocabulary settle around methods and tables.
The second aspect comes with supporting production problems. As programmers gain experience and move into senior roles, they are called into fix urgent problems faced by customers in live environments. The first steps almost always include looking at log files and the database. A lot of analysis centers around database tables and columns to understand the values or the state of the data.
Part of this comes from the fact that the customer-support guys are chasing development teams over emails and phone, some times even standing behind their back, so trying to debug through source code is not done every time as it takes a little bit more time to set up. Dealing with the log file exceptions, database values and Googling around gives quick fixes in a lot of cases.
Thus a programmer gets imbibed with relational structures thoroughly. When the production-support developers become the designers for the next release or the next module, they quickly get into the methods - tables thought process and vocabulary. The so-called object-relational impedance, even if it were existing previously, just disappears over time.
Hence the very premise, the insurmountable object-relational impedance, that led to building ORM frameworks is questionable. That's not the only problem. There started a new set of issues as Hibernate/JPA evolved.
People had to learn a new framework. The very idea of learning another framework seemed to be an additional responsibility, kind of a burden. It involved new APIs, first XML then annotations, and new configurations. In comparison, JDBC just seemed to be a natural part of Java with just seven steps to learn.
From my experience, I recall that Hibernate-based applications consume more hardware resources. In the era of hardware commoditization and 64-bit systems, this is normally not a problem. There are performance problems related to using Hibernate.
Of course, by using performance-improving techniques, we could address them. But then this meant spending time on learning those things, adding Hiberanate/JPa as a training topic for freshers, applying the performance-improving tips as an extra activity and retaining that knowledge within the groups. In the pre-ORM days, if application queries were taking a lot of time, you just moved some action to database procedures.
A lot of business operations and reports involve writing complex queries. Writing them in terms of objects and maintaining them seems to be difficult; it is easier to read and comprehend complex queries in terms of tables. In such cases, people prefer to write native SQL queries just overriding the persistence framework.
This is not to say that there is nothing good at all in Hibernate/JPA. The current thinking around Hibernate seems to be : if your application is primarily a CRUD-drive one, performance is not that critical, and as a development team you have a good say in the database design, you could just go for Hibernate/JPA. It would help achieve your goals in fewer lines of code than JDBC.
There are other benefits too. Lazy initialization patterns are already available in Hibernate, and they are not easy to hand code. Intelligent updates where only the updated fields are included in the SQL reduce network traffic. Since Hibernate is coming up with polyglot persistence, it would be easy to migrate to a NO-SQL database.
Considering the trade-offs, I would think that over a period of time, the development world will move away from Hibernate/JPA. At the moment, there are alternatives in the form of Spring JDBC and jOOQ, amongst others. I have looked at jOOQ briefly.
It reverse-engineers the tables to create java mapping classes and allows you to query the objects in an almost SQL like manner. The generated classes have the same name as the tables, so your Java code "reads" like SQL. I like it.
From the aspects of reducing the learning curve due to decreased boilerplate and annotations, and communicating via table names and SQL queries, jOOQ looks promising. It needs to be explored a bit more by developers. Figure out if it is tackling the unnecessary object - relational impedance problem or unnecessary boiler plate code. If it is just the latter case, then it's in the proper direction.
(Views are completely personal, I don't have any business interests with the makers of the frameworks mentioned in this article).
Comments
Post a Comment