For help with installation, bugs reports or feature requests, please head over to our new forums.
Genuitec Community on GitHub
- This topic has 90 replies, 69 voices, and was last updated 16 years, 11 months ago by
.
-
Posts
-
i am a consultant at a LARGE beverage company. they use ibatis for their multitude of legacy db’s. +1 for iBatis.
@support-rkalla wrote:
Guys from purely a technical standpoint, can some of you give your impressions of why you went with iBatis over Hibernate? Was this because the domain model was in place? How many of you decided to use iBatis even though you got to design the app from the ground up?
From my perspective, there are some very valid reasons to choose iBatis over Hibernate; besides those already mentioned (time to market, familiarity with SQL/DAO, etc). Consider an application which loads and persists very shallow object graphs (or single object instances) – which I encounter quite frequently. In this case, Hibernate is overkill; the problem maps very cleanly to discrete sql statements.
This, for me at least, is a primary factor in choosing between Hibernate and iBatis; if use cases involve large object graphs, or the domain mapping is more complex, then Hibernate is often a better choice. Hibernate’s multi-level caching strategy (and ability to more discretely evict objects from cache) are helpful as well.
Another case for iBatis over Hibernate is when dealing with legacy DBMS systems; I’ve had the dubious pleasure of having to write applications against DBMS systems with odd SQL dialects and no native JDBC drivers. I’ve also encountered situations where the client dictates a policy where all DB access MUST use stored procs; this is much easier to accomplish in iBatis than in Hibernate (at least in my experience).
My biggest complaint with iBatis is the amount of (redundant) typing involved to build an application; a gui tool would be a godsend here.
== Steve
+1 for iBatis.
In our enterprise we have DBA and web developers. The web developers write SQL, but when things need performance refactoring, we call in the SQL experts. Real SQL gurus can speed up complex queries 10x. We would lose these types of resources using a non-native SQL mapping tool.
Also, we have a ton of existing enterprise stored procs for many things.
+1 For iBatis
I am consulting at a large multi-national asset management company. They are promoting using iBatis company wide because of the better support for Stored Procedures over Hibernate. I havent looked at it much myself but I will be shortly.
Guys keep the requests comming, we are tracking all of them, we haven’t forgotten about this thread.
++iBatis – ‘cos even sql developers understand me when I show them it. (This is not necessarily a good thing 😉 )
Eclipse Plugin for iBATIS is available
http://ibatis.apache.org/abator.html
Abator is a code generator for iBATIS and is packaged as an Eclipse plugin … Abator will introspect database tables and generate iBATIS source code artifacts. You can hand code SQL code for custom queries, or stored procedures. Hand coded additions in generated Java classes or SqlMap files are preserved during subsequent code regeneration cycles.
Abator will generate:
* SqlMap XML Files,
* Java Classes to match the primary key and fields of the table(s),
* DAO Classes that use the above objects (optional)(description adapted from the plugin’s website)
