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>
- Re: Please Help in arguing for iBatis SqlMaps Kaushik Ashodiya
- Re: Please Help in arguing for iBatis SqlMaps Mark Bennett
- Re: Please Help in arguing for iBatis SqlMaps NetSQL
- Re[2]: Please Help in arguing for iBatis SqlM... Andrey Rogov
- Re: Please Help in arguing for iBatis SqlMaps Brandon Goodin
- Re: Please Help in arguing for iBatis SqlMaps Larry Meadors
- Re: Please Help in arguing for iBatis SqlMaps Clinton Begin
- Re: Please Help in arguing for iBatis SqlMaps J.F. Zarama
- Re: Please Help in arguing for iBatis SqlMaps Vic Cekvenich
- Re: Please Help in arguing for iBatis SqlMaps Fabio Insaccanebbia
- R: Please Help in arguing for iBatis SqlMaps Fabrizio Gianneschi