ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaushik Ashodiya <kaushik.ashod...@ucop.edu>
Subject Please Help in arguing for iBatis SqlMaps
Date Thu, 07 Apr 2005 17:55:32 GMT
Hi,

I have hard time arguing for iBatis SqlMaps (not because something wrong 
with SqlMaps).

Please give me more reasons so that I can convince them.

Their argument:
1. For small project SqlMap is adding unnecessary complexity.
2. Why learn one more tool when you have a simple base data access object 
that gives you connection, prepared statement and a result and does 
cleanup? (only when extended class calls cleanup() !!!)
3. Generally open source projects dies shortly and does not have support.
4. Adding many jars of those open source projects make out project more 
complex and un-maintainable.
5. What if SqlMaps goes out of market? It is fairly new and not hardened.




<my-peers-arguments>
Again to re-iterate a point I was trying to make yesterday, architecturally 
speaking you should always try and keep it simple (not on an individual 
application level) but as far as possible on an enterprise level.  I'm 
going to ask you the same question that I asked yesterday...what do you 
think are the advantages/disadvantages of O/R mappings for relatively small 
applications where persistance is not the deciding criteria (or for that 
matter not even a criteria)?(I've attached yesterdays email thread for 
Kevin since he didn't get that one :))

I'll list the disadvantages:
1) You add multiple third party jars (open source or otherwise), which you 
need to be aware of when building new apps.  These include components which 
the vendor will eventually provide if the market demand is high...
2)You add multiple configurations for each of those products, which you 
need to understand on how to tune in case there are performance issues.
3) Most of these components seem to be build on the current versions of jdk 
which take a decent time to hit mainstream commercial product support.
4) If these products are not built to a spec (even though they may end up 
driving a spec), the migration process becomes an added overhead.  Even 
when they do become a part of the spec, the implementation differences of 
the vendor of choice may be so different that you pretty much waste any 
advantage of early adoption.  If you are a vendor of a product, an 
effective early adoption can translate into you either being bought out by 
the bigger established vendor or you getting to be a key player in that 
space....but we don't fall in that category.
5)You need to be able to train existing resources to use the product 
(unless there is a plan to let go people and get "new" fresh resources who 
may have had experience with the adopted product).  Now if the existing 
resources themselves have a discomfort moving over to an object oriented 
paradigm, putting up them up against the challenges of going thru the 
learning curve of extra products further lowers the probability of success.
6) You increase the possibility of chaos and reduce flexibility of resource 
utilization.

Besides the six points above, I would not recommend use of products like 
iBatis in applications at UCOP is because in my opinion the applications 
that we do or have done are relatively small and O/R mapping for those 
kinds of apps is probably an overkill (again personal opinion.)  To some 
level Hibernate is a valid candidate for evaluation (taking into account 
that it is driving the EJB spec). But again, my business acumen says that 
IBM will definitely take care of that.

Now my perpective looking at the example below, one of the key 
shortcommings that I see is it couples the "Display/View" with the model 
(Data Access).... Basically what this means is that if you wanted to create 
the same object tomorrow from not a "non" database/jndi source, you would 
be re-writing the logic for creating the same object.  Another disadantage 
that I mentioned yesterday was if your display object gets created from 
multiple datasources (one db2, one sybase) transaction management becomes 
an issue....  How would you use iBatis in a system which does not need 
persistanc but needs transaction management?

Isn't the whole idea of going with some big commercial vendor like IBM to 
consolidate your infrastructure source so that you dont knock on different 
doors? Often such a vendor is selected based on how many services required 
by a business are provided by the vendor. Nothing against Hibernate or 
iBatis.  I'm sure they are great at what they are designed to do.  But each 
one of them doesn;t do all that we probably need  (they still  need an 
underlying EJB container.) If thats the case, why would you want to 
introduce the additional learning curve and the additional layer associated 
with each product? Do you truely think that it's a necessity?


Short of long: I would recommend usage of vendor supported spec based ejb 
conatiner for applications needing persistance or transaction 
management.  Eventually these will be simplified (if there is fear of 
complexity....thats an issue the specs and the commercial vendors like IBM 
will definitely answer).  If persistance is not required, use the existing 
framework component.  What that does is you dont have to code the basic 
JNDI lookups, creation of connections, clean ups.  Since you are pretty 
much just accessing data, there is no coupling between the dataaccess and 
object creation.  The learning curve is almost next to nothing.  So I'd 
recommend for the present continue usage of the existing "Model" framework...

Just a small note on the side we'll still need to maintain components that 
we develop to be UCOP specific...(e.g. Employee Object etc).  These will 
have to be harvested in a generic layer outside individual applications, 
else we commit the same mistake that was made on ucfy, fje and danris (you 
copy the same code over and over again!!)


I wasn't ever saying iBatis is an O/R tool...  that was for Hibernate (I am 
trying to get your view on advantages/disadvantages of O/R mappings for 
relatively small applications where persistance is not the deciding 
criteria.)  The last email was just providing my thought process for not 
recommending the use of products that probably have little or no advantages 
for a business like UCOP.

Its a perspective with substantiation.  In the end we should try to do 
things becuase they make sense to our environment, not just because it's 
cool technology.  Is there a significant business advantage to using either 
iBatis or Hibernate, considering that we have existing solutions, be it 
ucop framework's jdbc component (comparing it with iBatis) or EJB/CMP 
(comparing it to Hibernate).

I've listed some of the disadvanatges of using iBatis and Hibernate in our 
environment.  Just to be fair, let me try to list some Advantages:

iBatis:
1) Probably good documentation and support from user forums as compared to 
the ucop jar's jdbc component.  However, the design principle used for all 
ucop component is to enable novices to use it within minutes (and thats 
something that has already been proven)
2)Resources with iBatis experience can be hired (Is there a plan?)....

All right I guess I can't think of more reasons

Hibernate V/s CMP:
Actually I cant think of any advantages since I know we have a EJB 
container....

we should talk... it'll be an interesting discussion.


</my-peers-arguments>

Mime
View raw message