On 8/29/05, Don Brown <[EMAIL PROTECTED]> wrote: > > netsql wrote: > <snip /> > > Can we add iBatis DAO to Ti (not iBatis Implemnation or SQL MAPs, just > > DAO). It would reduce # of user questions. > > Using iBatis DAO, people can implement the DAO anyway (or they could > > replace the iBatis DAO). > > For example, they could use iBatis DAO implementing EJB, or Hibrenate or > > what ever. I use it for Lucene. It moves up the yard sticks and stays > > light. > > It also helps in impleneting the Dispatcher. Ex: if a chain does not > > match name, then a DAO "name" is called. > > Going with the simply development theme, we have talked about including > some sort of DAO framework for a "starter's kit" > or something along those lines. That'd probably include a simple SQL > mapping framework, Derby or HSQL, and perhaps > Middlegen. However, those would only be included in this kit, and not part > of Struts Ti core, as we want to support > multiple business and DAO strategies and frameworks. > > Don >
I'd suggest showing how to hook up to iBATIS or HIbernate in an example application, and then deciding if TI needs to create yet-another DAO framework. Many iBATIS user s have stopped using the iBATIS DAO framework, since they find using a dependency-injection framework, like Spring, works as well or better. Most DAO implementations are specialized cases of dependency injection. If you are already using Spring and interfaces, the value of a standard DAO framework is diluted, since you can always have Spring (or the equivalent) load an alternate implementation. The same is true if you are using CoR. If some of your commands are data-access commands, you can load an alternate data-access set by changing Catalogs. Life becomes very sweet when you use both Spring and CoR (which is what we do at work). We use Spring to load the Catalog, along with whatever other objects we need. -Ted.
