iBatis
So, I've done some looking into iBatis after a colleague (names are hidden to protect the innocent, so let's just call him Gike Mengler) recommended I check it out. Following my first Java-ORM experience (Hibernate), iBatis looks very appealing to me.
Looking back on my first Hibernate exposure, my biggest struggle was "giving up so much control" to Hibernate. That's in quotes because I realize that this is only my perception and an experienced Hibernate developer would surely argue that they gain a lot of control from Hibernate. My experience is/was that I was coming from an environment where I felt like I had a lot of control and could make my data retrieval and persistance do what I wanted... writing SQL statements with bells and whistles to shape data before mapping that data to Java objects with a custom framework has become second nature. It is what I've experienced in the vast majority of applications I've done to this point. In my specific Hibernate experience, this was not the case.
Another struggle was regarding unit testing. I was not too happy with Hibernate mappings coupling together mapping files which it views as being a single unit. I can see where it's coming from: in its eyes, it's populating and persisting (etc) all of these objects at once, so it makes sense that they should also be tested together. It makes sense in my head, but creating tests that make sense with this in mind proved challenging.
From what I've learned on iBatis in the last week, it makes no claims at being an ORM tool. Instead of "automatic" SQL statement creation, I have to (get to) provide my own SQL statents. I also can provide the logic needed to map them in a way that (to me) seems a bit more straightforward.
As it says in the first line on the iBatis homepage: Simplicity is the biggest advantage of the iBATIS Data Mapper over object relational mapping tools. I am looking forward to investigating the accuracy of this statement.
0 Comments:
Post a Comment
<< Home