ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antony Joseph" <ajosep...@lycos.com>
Subject The biggest problem with iBATIS ..............
Date Tue, 08 Mar 2005 16:30:31 GMT
Hi all,

I came across this on one of the other forums.

"The biggest problem with iBATIS is its too simple"

So here is a couple of suggestions to the iBATIS team to make the framework as complicated
as the much hyped ORM tools in the market.

1) iBATIS needs a new query language. SQL!, its sooo 20th century, everyone knows it, and
whats with this bias towards english. We live in  a global village, I suggest that the new
query language include terms from all continents.
2) It needs some kind of session management. All the other ORM frameworks have it, why not
iBATIS.


Since its seems these days the goal of a corporate consultant is to make sure the application
costs as much as possible and takes as much time as possible, here is a synopsis of the conversation
a consultant will have with the project manager using the new iBATIS(or your favorite ORM
framework).

1) As you know the framework uses a new query language, your developers need to be trained
on it. My company X provides a 3 day training course. Its just $xxxx.xx per person. Don't
forget to include the DBAs for training. cha-ching!
2) Your developers seem to be ignorant of  ORM design patterns  like 'Open session in view',
'session-per-request-with-multiple-transactions' .... etc . My company X provides a 1 day
training course for ORM patterns. It just xxxx.xx per person. cha-ching!
3) What!, your the DBAs want to denormalize the tables. This is a problem, but we can solve
it. The will cause the queries to get complicated (Actually the queries start looking more
like regular expressions than queries) and it will take X weeks more and cost Y dollars more
to complete the project. cha-ching!

4) Those SOB users. They want to query data with something other than the primary key!. We
can take care of their requirements, but now, we will have to write a whole bunch of dynamic
queries to take care of all the different query combinations. This will delay the project
by another X weeks and cost X dollars more. cha-ching

5) And when the totally confused junior programmer (confused by session management and the
query language) writes a query which reads the whole graph of data from the database bringing
the application to a crawl: 
Mr project manager, my company X has a caching framework, its only $xxxxx.xx/per CPU. Plug
that in and all your problems will be solved.
cha-ching, cha-ching, cha-ching.


Imagine the name recognition new iBATIS will get. A whole bunch of confused developers will
be asking questions on this forum, and then on the Spring forum, and then the struts forum
and finally if all else fails, ask them on Matt Raible's blog. Thats publicity money can't
buy.


So my question to Clinton and gang is, are you going to incorporate these changes or follow
on the same old beaten path of adding new features and making the framework simpler to use?

 



Antony Joseph
http://www.logicden.com
https://workeffort.dev.java.net

-- 
_______________________________________________
NEW! Lycos Dating Search. The only place to search multiple dating sites at once.
http://datingsearch.lycos.com


Mime
View raw message