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