Wow, I think this is going to be a fun thread.
On Apr 7, 2005 1:55 PM, Kaushik Ashodiya <[EMAIL PROTECTED]> 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> >
