ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From NetSQL <maill...@friendVU.com>
Subject Re: Please Help in arguing for iBatis SqlMaps
Date Fri, 08 Apr 2005 01:42:44 GMT
Kaushik Ashodiya 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.

Re-use of working thing... vs writing your own bugs and documenting.

> 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.

If you don't need cache, don't use it. Else set # of minutes.

> 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.

?? vs what?

> 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.

Yeah, JST # 123 vs Apache. Which is more standard?

> 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.

Maybe good docs would help. And make it stnadarad ANSI SQL.

> 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.)

Maybe better to avoid hevy O/R.

> 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.  

IBM does have a J2EE reputation. Like it's the worst.

> 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.)

 Hibreante and iBatis don't.

> 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? 

Yes, Keep it Simple.

> 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

Yes, in version 4 or 5 you think?

> (if there is fear of complexity

I see that you are not afraid of complexity. You must be a "high" level 

> ....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...

Something propriatory? No docs? No Unit test? No track record? No mail 
list supoprt?

> 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).

Makes sense.

> 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?)....

Or they can pick it up. It's SQL you know,

> 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.... 

EJB is the ultimate Hibreante.

> we should talk... it'll be an interesting discussion.
> </my-peers-arguments>

I think it best to steer clear of religious wars. If they don't want to 
re-use Apache, OK. If they LIKE EJB and/or IBM, then start learning .NET 
or PHP.


View raw message