Hibernate JDBC Debate

Question

This might not be strictly a Java Programming question, but given the expertise and experience in this forum regarding OOD/Hibernate/JDBC I
thought it would be a useful place to post this. Apologies if you don't think this is the appropriate place.
Background: I work in MDA (model driven architecture) and the company I work for right now has implemented a system with UML for meta-modeling
and we use Hibernate and MySql for the resulting model's data repository. From that data we are generating documentation and multiple types of code.
We recently hired a co-op who has been railing against Hibernate since day one. He rails against the uses of reflection and insists that JDBC is much
better. He recently wrote me an email containing his 'research' and conclusions on the subject. I thought it would be interesting to see the
responses from people who have more experience than in development/OOD/Hibernate and so on.
My inline responses to his email are preceded by '[N]'.
(My initial reply, in addition to inline)
I mention this below, but I�ll also say this at the top here... You are looking at this from the database perspective. But the database only supports the
model. In fact, it is a result of the model. It gave us a convenient way of storing the model information (which is a common paradigm in MDA, btw).
Because we started with class modeling, it only makes sense to think in classes/objects.
--------------------------(Co-op's email)
Neil,
I�ve been doing some research in my free time on JDBC, and the MySQL-Connector/J driver. I�ve got a program that I�ve written in Java to do
[irrelevant task x] that uses a database. Just for the sake of comparison, I set up this program to use Hibernate; I read all of the relevant documentation
and created all of the pojos by hand (there weren�t many). After I completed that task, I created a tag in my CVS server, and ripped out all of the hibernate
code, so I was back to a clean slate with simply a JDBC connection maintained by my Database class. I re-implemented everything that I had done with methods such as �public void createSomeInformation(�) throws
SQLException�, and �public RecordSet getSomeInformation(�) throws SQLException� � these methods used java.sql.PreparedStatements to
execute SQL, and return RecordSet objects, which are essentially the result of any given SQL query that�s either a SELECT or otherwise returns
information in a table-format.
So, why did I go through this huge exercise? I was convinced that Hibernate wasn�t worth the effort; now I�ve got enough experience with both options to
discuss them intelligently. I hope you like a good healthy argument, because I feel pretty strongly about this particular topic, and I am very interested to see
what you have to say. This is what I�ve learned:
Hibernate is really, really cool if you want to pretend that databases are object-oriented. It sounds like a Java programmer�s wet dream, but consider
the following:
- Object oriented crap is still crap.
[N] So are you saying OOD is wrong?
- It hasn�t really taken all of the work out of writing software, because you had to make a UML model of the database to generate the pojos. If it weren�t for
the code generator, you�d have put that work in to writing pojos by hand. The XML file is also some finite amount of work to maintain.
[N] The XML generator was broken for NT. That�s why I had to unfortunately maintain stuff by hand. I�ve been working with GRI to fix these problems.
Secondly... The database isn�t the model. The model (UML) is the model. The database (as well as the Hibernate code) is the result of the model. We
didn�t design a database, then come up with a UML schema to create Pojos to access it. We designed the model, then generated the schema and pojos
to create a repository for the data.
- Hibernate relies heavily on reflection. We had the short version of this conversation a couple of weeks ago, but I�d like to qualify my distaste for
reflection. It isn�t inherently bad; it�s all about implementation. Hibernate uses reflection to watch for access to fields of a class, so it can lazily
populate them from the database.
[N] So what?
Let�s recap on some basic object oriented philosophies:
Object oriented philosophy 1: Classes have responsibilities. Bend this if you like, even break it if you�re sure it�s the right thing to do, but never forget
where it came from. If a class doesn�t have a responsibility, it doesn�t have a purpose. If it doesn�t have a purpose, its actions are irresponsible � if it isn�t
the classes job to do a task, it should not do that task!
[N] What tasks do the pojos have that you don�t think they should do?
Object oriented philosophy 2: Responsibilites are simple, and clearly defined. Complicated responsibilities mean complicated code. Everything
can be viewed as the sum of its parts, and the class structure should reflect that.
[N] What�s complicated about the pojos? They seem pretty simple to me.
Object oriented philosophy 3: Responsibilities are really, really simple. Like, so simple you can figure out what they are by looking at the name of the
class. Ask yourself, �What does a java.lang.String do?� What about a java.io.FileReader? Now, without cheating, tell me what a
com.airvana.sde.db.BuiltinTypePvtIface is.
[N] BuiltinTypePvtIface is not a class, it is an interface. So, you are trying to compare classes to an interface. Why is it unclear what a class like
ManagedObjectImpl, for example, is to you? Additionally, that interface it is a private interface that only the implementation class uses (BuiltinTypeImpl).
Ask ******(the original designer) why he did this. You�d get a better answer from him than me.
So what this all boils down to is that Hibernate is trying to take something that simply doesn�t fit in an object oriented world, and make objects out of it.
A database�s table can�t be a responsible java class; it�s not a java element, and to ask it to be one is absurd. Things that are java elements, however,
include the data types that the database uses. A set of these types can be put together to form a row. A set of rows can be put together to form a
ResultSet (which is different from a table, because a table is the authorative copy; it�s the database�s responsibility to maintain that).
[N] So, you�ve refuted, in a weekend�s worth of work, about 20 years (at least) of Object to relational mapping theory and application?
If you�re familiar with database normalization, you should know that step one is to remove duplicate data. There�s a similar strategy in object oriented
analysis/design, where you take a set of absurdly repetitive classes, and combine all of the things that are reusable.
Let�s pretend hibernate doesn�t need a specific format of pojos to operate, and we can define table classes however we want. If we were to look for the
commonality among table pojos, this might be what we come up with:
public class DatabaseField {
            public DatabaseField(String fieldname, Class fieldtype) {
                        // �
public class DatabaseTable {
            public DatabaseTable(String tableName, DatabaseField[] fields) {
                        // �
            public void insert(DatabaseField[] fields, Object[] values) {
                        // �
            public Object[] select(DatabaseField[] fields, �) {
                        // �
}I�m not going to finish implementing these classes, because I don�t really have any desire to use them, but they are still 100x more responsible than
any hibernate pojo ever could be.
Right now I�m anticipating the argument that hibernate pojos are responsible because the represent specific tables. Well, that may be true,
but it violates the reusability rule. The following code is re-used about 10,000 times:
        // Now make sure we have only one parent
        if(myParentCheck != 1)
            // this is not good, we have no parent
            // or more than one parent
            throw new java.lang.RuntimeException("Instance has no parent or more than one parent") ;
        return myCompParent.getCompositionRootElement();That only needs to be written once.
[N] This code is generated code... The point of code reusability is to prevent hand-written code from having to be written over and over again, thus
introducing errors. It�s a practicality issue and a debugging issue. If this
code wasn�t generated (therefore, guaranteed to be the same) then I�d agree
with you here.
Back to my original point: hibernate uses reflection to lazily initialize its data. If hibernate pojos looked like the model above, they wouldn�t need to use
reflection and lazy initialization, because they would all have a common format � perhaps even an interface that�s re-used more than once.
[N] You studied how to use hibernate, but you keep arguing against reflection, etc. You seem to be arguing more against Hibernate�s
design/implementation itself. Perhaps you should talk to Hibernate developers and delve into Hibernate�s design to see why it was done the
way it was done and speak to them on how to do it. I�m not expert in Hibernate�s design, so I�m not to person to talk to here.
I'm very interested to see other responses, both to the co-op and to myself (am I right, or completely wrong?). Your insights will be highly
valued.

Answer 1

It's hard for some coders to use 3rd party solutions
knowing they can write a better solution. Personally
I feel there's a bigger move away from this coding
style as it's expensive/time consuming/counter
productive and usually for very little advantage.True... In my case though, I found this easy to use, even coming in from "the cold" so to speak. I was using this particular solution only a few months
after learning Java.
While it may be expensive in terms of a code-base, that code base is bought with the push of a button from our modeling tool.
I could write the GUI without having to worry about implementing JDBC and such. Just use getters and setters and familiar java objects and "bang! Yer done".
Hibernate is a generic solution and so by this very
nature a bespoke solution would be better.The origins of this set-up come from a purposefully generic solution. It came from a MDA consulting company (of which I was originally part of <the plot
thickens, eh?>) that was developing this solution to be used by multiple customers, much like MindConstructor or AndroMDA.
If you take this argument one step further then why
use an RDBMs? Why not create your own persistence
implementation fine tuned to your application? I don't think there's any issue with using the RDB. I think we all feel here that it is a good solution. Plus, given the time constraints of the project to get it
operational, we didn't really have time to develop some sort of custom persistence implementation.
I believe for the same reasons that you would use
Hibernate - a code base in wide use will benefit from
better bug identification and resolution therefore
making a more stable platform.That is the one area where I have been working with the MDA company to improve. The generated code isn't bad, but it could be better.
Does that require that we throw it away and try to re-implement with a different solution though?