ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Bennett <mark.bennett.m...@gmail.com>
Subject Re: Please Help in arguing for iBatis SqlMaps
Date Fri, 08 Apr 2005 01:14:39 GMT
Wow, I think this is going to be a fun thread.


On Apr 7, 2005 1:55 PM, Kaushik Ashodiya <kaushik.ashodiya@ucop.edu> wrote:
> 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