You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Kaushik Ashodiya <ka...@ucop.edu> on 2005/04/07 19:55:32 UTC
Please Help in arguing for iBatis SqlMaps
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
Posted by Mark Bennett <ma...@gmail.com>.
Wow, I think this is going to be a fun thread.
On Apr 7, 2005 1:55 PM, Kaushik Ashodiya <ka...@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>
>
Re: Please Help in arguing for iBatis SqlMaps
Posted by Brandon Goodin <br...@gmail.com>.
You know... I can appreciate an informed opinion. But, your peer is
clearly lacking in his assessment. All i can say is that you peer has
some absurd notions and ridiculous antidotes. They clearly don''t
understand the nature of the technologies they are talking about. I
really don't feel like fighting against egregious and irresponsible
ignorance. I'd much rather discuss intelligent objections and ideas.
However, i'll throw in a few comments. I truly don't care to get mixed
any deeper into this.
--------------------------
Their argument:
1. For small project SqlMap is adding unnecessary complexity.
This is ridiculous. It adds simplicity. That is it's nature. JDBC MADE
EASIER. iBatis handles all the mundane work that would do by hand
coding JDBC anyways. So, where is the complexity? I've used iBatis on
complex and simple systems alike.
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() !!!)
Not sure if you are referring to a home spun solution or jdbc.
Regardless, it is still a mute point. iBatis is super easy to
understand. It is an OSS project that has the support of a strong
community and therefore relieves you from having to maintain the code
base alone.
3. Generally open source projects dies shortly and does not have support.
I can't say how ridiculous this is. Look throughout the history of
technology. It is the OSS products that have survived and thrived
across the years But, let me say, that is why we have joined the
Apache group. Apache has a rigorous process of analysis to make sure
that the projects it adopts are long living projects with a happy
healthy community. BTW iBatis has thrived on it's own for over 2 years
now. We are hardly short lived. Also, we have a .NET version of our
framework and there is discussion of a PHP and Ruby version.
4. Adding many jars of those open source projects make out project
more complex and un-maintainable.
This one is hardly worth commenting on. What project does not include
jars? Are they suggesting that proprietary products somehow have less?
Wow, ignorance abounds. However, let me also say that iBatis goes
through great care to reduce dependencies on jars. We have very few
dependencies and most of them you would need anyways with a database
project.
5. What if SqlMaps goes out of market? It is fairly new and not hardened.
Will SQL go out of market? Will JDBC go out of market? answer those
questions and you will have your answer.
--------------------------
RE: <my-peers-arguments>
"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..."
The vendor generally foists copious amounts of unnecessary crap on you
as it is. Wouldn't it be nicer if you have a clean decisive stack.
Your peer seems to be contradicting themselves.
So, jars are okay to fill your project so long as they come from a vendor?
"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."
iBatis tuning is simple and the config files are simple too. If you
can or do code JDBC you can iBatis. The configurations are merely
containers for your SQL code. If that's too much for someone then i
suppose they should find a new means to access the database with Java.
"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."
iBatis is JDK 1.3 compatible
"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."
Okay another nonsense argument. It's not a spec. But, if it was a spec
we would face the same problem as those things that are not a spec.
What exactly is this person arguing? Do they want to write everything
by hand internally and avoid external dependency? Think of this... if
by some chance ibatis stopped... you could pick up the ball and keep
coding it. Or if your buddy thinks that using some framework that has
been established by a large corporation will somehow serve you better
then that is silly too. Every product has it's lifecycle and upgrading
is a reality. However, with iBatis we have gone through significant
effort to make those transitions easier. You only see backward
breakage when it comes to version releases. That being said we made it
possible to migrate from 1.x to 2.x with GREAT ease compared to the
hoops many of the larger corporate dealers force you through for
upgrades.
"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."
This is true. But, isn't this the case with ANY product. I believe in
investing in commodity skills for a large company. But, that is why
iBatis has remained close to SQL and JDBC avoiding the complex and
convoluted route of the O/R sliver bullet. BTW, we are not O/R. We are
a SQL Mapping Tool. We do not map tables to Objects.
"6) You increase the possibility of chaos and reduce flexibility of
resource utilization."
I think this is a bit melodramatic and overstated. You certainly have
to be concerned about unneeded complexity. But, if you are going to
code straight JDBC you will face more complexity than iBatis.
"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)...."
Again, this is simply NOT true and it hurts to even comment on this.
iBatis follows a common and WELL accepted approach called the DAO
pattern. iBatis should in no way be accessible to the view. But, this
is hardly something we can prevent people from doing. IBM can't even
prevent stupid people from being...well... stupid.
"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...."
Spring provides a great means of cross database transaction
management. We are currently working on JTA support. Also, I thought
your peer just got done saying these were simple apps?
"ts 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."
I totally agree!!! However, i would caution your peer on trying to
sound intelligent about things they know nothing about. They should
take a few minutes and understand something before criticizing it with
ridiculous statements.
"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?)...."
The fact that your peer can't comment on the realities of the
advantages further underscores their irresponsible ignorance. They
should temper their opinion with reality, not conjecture. iBatis is
excellent for novices and gurus alike. iBatis resource can be hired
because all you need to put into the job description is "Must know
JDBC". I think you will find plenty who meet that criteria.
"Hibernate V/s CMP:
Actually I cant think of any advantages since I know we have a EJB
container.... "
<sarcasm>
And we all know EJB has been a raving success and pinnacle of
simplicity and design precision.
</sarcasm>
--------------------------
Hopefully i haven't been too harsh here. I just don't think your peer
understand the proposed solutions. It sounds to me like they have
taken just enough time to research why your company should NOT use
iBatis or Hibernate. Rather, they should take time to understand how
these technologies could actually assist your development. The focus
and intent of their argument is colored by their clear intent to
undermine ever thing that isn't packaged and distributed by IBM and/or
coded and maintained in house.
One final question, did this "peer" develop the current data access
solution. It sounds a bit like there is an ego issue floating around
in the argument.
Man! i said i was gonna be short... guess i was a bit more enthusiastic.
Brandon
On Apr 7, 2005 11:55 AM, Kaushik Ashodiya <ka...@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>
>
Re: Please Help in arguing for iBatis SqlMaps
Posted by Vic Cekvenich <ne...@roomity.com>.
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.
It's simpler than JDBC.
> 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() !!!)
Becuase you do not even have to do any of that, it's simpler.
> 3. Generally open source projects dies shortly and does not have support.
Yes!
> 4. Adding many jars of those open source projects make out project
> more complex and un-maintainable.
vs writing NEW code, unit testing and documenting.
> 5. What if SqlMaps goes out of market? It is fairly new and not hardened.
I've used it for a few years on several clients. I never discsuss
technology w/ client, I just talk about reqruiemtns and screens. So it's
not new and it has a lot of users.
.V
>
>
>
Re: Please Help in arguing for iBatis SqlMaps
Posted by Larry Meadors <la...@gmail.com>.
Heheheh, this is funny.
OK, here is an iBATIS application.
It is not the best example, but it shows how nonsensical this statement is:
"For small project SqlMap is adding unnecessary complexity."
===
Main.java
===
package blah;
import com.ibatis.sqlmap.client.SqlMapClientBuilder;
import com.ibatis.sqlmap.client.SqlMapClient;
import com.ibatis.common.resources.Resources;
import java.io.Reader;
import java.util.List;
public class Main {
public static void main(String arg[]) throws Exception {
String resource;
Reader reader;
List list;
SqlMapClient sqlMap;
resource = "blah/SqlMapConfig.xml";
reader = Resources.getResourceAsReader (resource);
sqlMap = SqlMapClientBuilder.buildSqlMapClient(reader);
list = sqlMap.queryForList("getAll", null);
System.out.println("Selected " + list.size() + " records.");
System.out.println("--------------------");
for(int i = 0; i < list.size(); i++) {
System.out.println(list.get(i));
}
System.out.println("--------------------");
}
}
===
OH! I almost forgot the configuration files!
===
SqlMapConfig.xml
===
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE sqlMapConfig
PUBLIC "-//iBATIS.com//DTD SQL Map Config 2.0//EN"
"http://www.ibatis.com/dtd/sql-map-config-2.dtd">
<sqlMapConfig>
<settings cacheModelsEnabled="true"
enhancementEnabled="true"
lazyLoadingEnabled="true" maxRequests="32"
maxSessions="10" maxTransactions="5"
useStatementNamespaces="false" />
<transactionManager type="JDBC" >
<dataSource type="SIMPLE">
<property name="JDBC.Driver" value="com.mysql.jdbc.Driver"/>
<property name="JDBC.ConnectionURL" value="jdbc:mysql://localhost/test"/>
<property name="JDBC.Username" value="root"/>
<property name="JDBC.Password" value=""/>
</dataSource>
</transactionManager>
<sqlMap resource="org/apache/mapper2/ii15/SqlMap.xml" />
</sqlMapConfig>
===
And here is the second one:
===
SqlMap.xml
===
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE sqlMap
PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN"
"http://www.ibatis.com/dtd/sql-map-2.dtd">
<sqlMap namespace="ii15">
<select id="getAll" resultClass="java.util.HashMap">
select * from user
</select>
</sqlMap>
===
Now, where is the complexity?
I think brandon may have hit the nail on the head...who wrote the framework
that your peer wants to use?
Larry
Re: Please Help in arguing for iBatis SqlMaps
Posted by Fabio Insaccanebbia <fi...@gmail.com>.
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0502cline/
iBatis is not a stranger for "big players" (e.g.: IBM)
In fact they (IBM) produced docs about integration with their products.
Not to say that IBM supports iBatis, but they certainly find it not
"totally unsuitable" for their architecture.
Kaushik Ashodiya wrote:
> 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.
(...)
>
> 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?
>
(...)
> 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).
(...)
<http://www.insac.com/>
Re[2]: Please Help in arguing for iBatis SqlMaps
Posted by Andrey Rogov <ko...@i-c.com.ua>.
Hi Vic !
Why do you think so about IBM reputation?
And whose reputation is the best? BEA?
>> 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.
N> IBM does have a J2EE reputation. Like it's the worst.
N> I think it best to steer clear of religious wars. If they don't want to
N> re-use Apache, OK. If they LIKE EJB and/or IBM, then start learning .NET
N> or PHP.
N> .V
--
regards,
Andrey mailto:konus@i-c.com.ua
Re: Please Help in arguing for iBatis SqlMaps
Posted by NetSQL <ma...@friendVU.com>.
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
programmer.
> ....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.
.V
Re: Please Help in arguing for iBatis SqlMaps
Posted by "J.F. Zarama" <jf...@gmail.com>.
Further help from IBM to newcomers on the subject include:
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0502cline/
http://www-1.ibm.com/support/docview.wss?uid=swg4f0a6040763358eee85256f9c005cad80
http://www-128.ibm.com/developerworks/opensource/newto/
http://www-128.ibm.com/developerworks/opensource/library/os-merrier.html
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0410prial/
http://www-128.ibm.com/developerworks/opensource/library/os-worldos.html
http://www-128.ibm.com/developerworks/xml/library/x-think15/index.html
jfz.
On Apr 7, 2005 11:34 PM, Clinton Begin <cl...@gmail.com> wrote:
> Hi Kaushik,
>
> I was going to respond with a technical rebuttal, until I read: "my
> business acumen says that IBM will definitely take care of that".
> (apparently from your supervisor or something)
>
> Let me instead tell you how IBM made $96 Billion dollars in 2004. Or you
> can read it yourself at:
> http://www.ibm.com/investor/filings/index.phtml
>
> IBM basically makes money in two ways: 1) By selling software (that may or
> may not work) and 2) By selling services to "help" you with that software.
> The profit from these services is about 50/50 and together they make up 70%
> of their total profits (their proprietary hardware makes up another 25%).
>
> Because 35% of IBM profit depends on also selling you services, it's in
> their best intersts to offer you products that are over complicated,
> underdocumented and that generally don't work well (i.e. WebSphere). It
> simply makes business sense. If you doubt my motives for this, let's look
> at how IBM spends their money.
>
> All of IBMs expenses can be categorized in two areas: 1) Sales, General
> and Administration and 2) Research, Development and Engineering. They spend
> 80% of their money on SG&A and a measly 20% of it on RD&E.
>
> So, when we look at how IBM makes and spends money we see this:
>
> * IBM depends on selling you complex software and proprietary hardware
> * IBM depends on selling you services to support, extend and maintain that
> software and hardware
> * IBM spends 4x more money on SELLING you these things, than IMPROVING them
> * IBM makes you pay for all of this up front, but you won't know how bad it
> really is until your project fails
> * IBM is a sales organization that succeeds in business by taking your
> executives out for lunch.
>
> In contrast, open source software:
>
> * Depends on compatibility and openess to achieve network effect
> * Depends on an energetic community of smart people to keep it alive
> * Spends 100% of resources on IMPROVING the software and none on selling it
> (except for this thread) ;-)
> * You don't pay a dime for it EVER whether your project succeeds or
> fails...you're never any worse off
>
> Open source software succeeds solely on its merits.
>
> Chances are your organization will still choose to buy into IBM (or Sun, or
> HP, or Microsoft, or ...). I see it happen every day in large companies.
> The other nice thing about open source software though, is that no matter
> what your boss chooses...I don't lose a dime. ;-)
>
> Cheers,
> Clinton
>
> On Apr 7, 2005 10:55 AM, Kaushik Ashodiya <ka...@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>
> >
>
>
Re: Please Help in arguing for iBatis SqlMaps
Posted by Clinton Begin <cl...@gmail.com>.
Hi Kaushik,
I was going to respond with a technical rebuttal, until I read: "my business
acumen says that IBM will definitely take care of that". (apparently from
your supervisor or something)
Let me instead tell you how IBM made $96 Billion dollars in 2004. Or you can
read it yourself at: http://www.ibm.com/investor/filings/index.phtml
IBM basically makes money in two ways: 1) By selling software (that may or
may not work) and 2) By selling services to "help" you with that software.
The profit from these services is about 50/50 and together they make up 70%
of their total profits (their proprietary hardware makes up another 25%).
Because 35% of IBM profit depends on also selling you services, it's in
their best intersts to offer you products that are over complicated,
underdocumented and that generally don't work well (i.e. WebSphere). It
simply makes business sense. If you doubt my motives for this, let's look at
how IBM spends their money.
All of IBMs expenses can be categorized in two areas: 1) Sales, General and
Administration and 2) Research, Development and Engineering. They spend 80%
of their money on SG&A and a measly 20% of it on RD&E.
So, when we look at how IBM makes and spends money we see this:
* IBM depends on selling you complex software and proprietary hardware
* IBM depends on selling you services to support, extend and maintain that
software and hardware
* IBM spends 4x more money on SELLING you these things, than IMPROVING them
* IBM makes you pay for all of this up front, but you won't know how bad it
really is until your project fails
* IBM is a sales organization that succeeds in business by taking your
executives out for lunch.
In contrast, open source software:
* Depends on compatibility and openess to achieve network effect
* Depends on an energetic community of smart people to keep it alive
* Spends 100% of resources on IMPROVING the software and none on selling it
(except for this thread) ;-)
* You don't pay a dime for it EVER whether your project succeeds or
fails...you're never any worse off
Open source software succeeds solely on its merits.
Chances are your organization will still choose to buy into IBM (or Sun, or
HP, or Microsoft, or ...). I see it happen every day in large companies. The
other nice thing about open source software though, is that no matter what
your boss chooses...I don't lose a dime. ;-)
Cheers,
Clinton
On Apr 7, 2005 10:55 AM, Kaushik Ashodiya <ka...@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>
>
Re: R: Please Help in arguing for iBatis SqlMaps
Posted by Larry Meadors <la...@gmail.com>.
Not to mention the added maintenance cost. ;-)
On Apr 8, 2005 2:32 PM, Brice Ruth <bd...@gmail.com> wrote:
>
> Roll your own, and you have that much more
> QA to do.
>
Re: R: Please Help in arguing for iBatis SqlMaps
Posted by Brice Ruth <bd...@gmail.com>.
Remember, you're looking for best-of-breed and best-practice for right
here, right now. Nobody has a crystal ball, nobody knows what tomorrow
holds. However, if you roll-your-own, every knowledgeable Java
developer and architect out there will tell you that its a waste in
almost every scenario. Code re-use and component architectures allow
for fast time-to-delivery. Roll your own, and you have that much more
QA to do.
BR
On Apr 8, 2005 9:27 AM, Fabrizio Gianneschi
<fa...@gruppoatlantis.com> wrote:
> Kaushik Ashodiya wrote:
>
> >Please give me more reasons so that I can convince them.
> >
> >Their argument:
> >1. For small project SqlMap is adding unnecessary complexity.
>
> I evaluated iBATIS expecially on small-medium projects.
> It reduces the "ordinary-JDBC" Java code by ~62%
> http://www.jugsardegna.org/vqwiki/jsp/Wiki?IBatisCaseStudy
> Most of the DAO methods are now 1 line long. (I wasn't able to reduce them
> more, sorry :))
>
> Can your homemade framework do the same?
>
> >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()
> !!!)
>
> I don't want to think about cleanup or opened connections left.
> I don't want to repeat the
> "try-getConnection-prepare-set-execute-while-new-set-add-finally-close-close
> -close" prayer anymore.
>
> >3. Generally open source projects dies shortly and does not have support.
>
> Even if iBATIS would die tomorrow, its actual codebase is better than every
> other framework I could develop within months (or years).
>
> >4. Adding many jars of those open source projects make out project more
> complex and un-maintainable.
>
> That's why Ant, Maven and other build systems exists. Ya-ha-wn.
>
> Every (few) jar included in iBATIS is far more maintanable than an homemade
> framework, on which you've to spend your valuable time.
>
> >5. What if SqlMaps goes out of market? It is fairly new and not hardened.
>
> Try it. I don't reply to your peers arguments... other people responded very
> well here.
>
> Fabrizio
>
>
--
Brice Ruth
Software Engineer, Madison WI
R: Please Help in arguing for iBatis SqlMaps
Posted by Fabrizio Gianneschi <fa...@gruppoatlantis.com>.
Kaushik Ashodiya wrote:
>Please give me more reasons so that I can convince them.
>
>Their argument:
>1. For small project SqlMap is adding unnecessary complexity.
I evaluated iBATIS expecially on small-medium projects.
It reduces the "ordinary-JDBC" Java code by ~62%
http://www.jugsardegna.org/vqwiki/jsp/Wiki?IBatisCaseStudy
Most of the DAO methods are now 1 line long. (I wasn't able to reduce them
more, sorry :))
Can your homemade framework do the same?
>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()
!!!)
I don't want to think about cleanup or opened connections left.
I don't want to repeat the
"try-getConnection-prepare-set-execute-while-new-set-add-finally-close-close
-close" prayer anymore.
>3. Generally open source projects dies shortly and does not have support.
Even if iBATIS would die tomorrow, its actual codebase is better than every
other framework I could develop within months (or years).
>4. Adding many jars of those open source projects make out project more
complex and un-maintainable.
That's why Ant, Maven and other build systems exists. Ya-ha-wn.
Every (few) jar included in iBATIS is far more maintanable than an homemade
framework, on which you've to spend your valuable time.
>5. What if SqlMaps goes out of market? It is fairly new and not hardened.
Try it. I don't reply to your peers arguments... other people responded very
well here.
Fabrizio