Hi Jaaron, I have a lot of respect for your development skills, so it pains me to have to point out a few things:
1) You've obviously not used DAO 2.0. Many of your design concerns that you mentioned above have been resolved (no more static methods, and extra properties no longer exist at all!). 2) The iBATIS DAO framework is not intended to be a "container" as you've put it. You can draw parallels, but that doesn't make it so. Because a horse has 4 legs and a tail, that does not make it a dog. 3) The framework has always been the combination of two things: factory and a Transaction Manager. The 2.0 framework now injects (very specific) the key dependency, which is the DAO manager. Yes this is a circular relationship, but as you're about to see, it's no easier to abuse than what you've suggested... 4) The injections you've described are actually DAO anti-patterns. First, a DAO should never access another DAO. This creates a web of dependencies at your persistence layer --injected or not, it's not a good idea. Second, and worse yet, is that a DAO should NEVER start and stop transactions. DAOs are transaction participants, not transaction controllers. Transactions should be demarcated at a higher level, such as the service layer or even declaratively in the app server (both easily supported by the 2.0 implementation). 5) Spring can be used for ANY kind of application and with any combination of presentation and persistence tier frameworks. Indeed, I'm sure you could probably embed a Spring app in a cell phone if you wanted. That said, I'll admit that Spring can be more than some people need or perhaps want. In those cases, iBATIS or a custom written DAO framework are an excellent choice. 6) It is true that I have a great start on a new DAO framework. It is in fact not just a DAO framework, but a full blown IOC container with transaction management, security etc. The biggest questions on my mind are these: Does the world need another IOC container? Does that IOC container have to be iBATIS? Like I said Jaaron, I respect you as a developer and I think you have some good ideas. I'm just not sure you're in the right place. The way I see it, DAO would be a feature of an IOC container...not the other way around (which is what you're suggesting). What I'd suggest is this: talk to the Pico team. Aslak and Paul are good guys and want to hear what you have to say. Pico is the basis of a layered container architecture (pico, nano, etc.) which I've heard they intend to grow. One of those layers will include services like TX management and probably DAO. Your contributions to that effort would probably be appreciated. If they say "no", come back here and we'll see what we can do together, even if not part of iBATIS. Cheers, Clinton On Sun, 30 Jan 2005 21:06:16 -0500, J Aaron Farr <[EMAIL PROTECTED]> wrote: > > On Sun, 30 Jan 2005 17:58:49 -0700, Brandon Goodin > <[EMAIL PROTECTED]> wrote: > > Thanks for your input. > > > > When someone wants DI/IoC we recommend Spring. They don't use the DAO > > framework at all. What they DO provide is transaction management and > > DI across various persistence mechanisms (jdbc, ibatis sqlmaps, > > hibernate, ...). > > One of the reasons I like a simple stand-alone DAO framework (as opposed > to just pointing people to Spring) is that then I can use it in any > application such as desktop apps and with any framework such as Struts. > Of course, a DAO framework is not that hard to write, but I feel that > most developers don't understand the benefits of using one and end up > misusing the DAO pattern in general. > > > I know Clinton has worked on a replacement for the > > DAO framework because we are all aware of it's shortcomings in light > > of current technology practices. A prototype has been created. But, > > the OSS implementation has been slow to come and i'm not sure if/when > > it will make an appearance in the ibatis project. > > I created my own DAO framework inspired by iBatis which is available via > SourceForge. It contains most of the features I discussed in my first > email: http://jingdao.sf.net > > > So, i don't see a whole lot of desire in the team to refactor the DAO > > framework. We want to simply let it be what it is and role out a new > > product when the time is right. > > Any idea when that will be? :) > > > Also, i think there is considerable discussion to be had regarding > > whether to use an existing IoC/DI container or build in the > > functionality for it with a narrower scope than generic IoC containers > > offer. Also, in the course of deciding to use an existing IoC > > container or not the discussions needs to be had about which one we > > would use. Personally, I made a decision not to use pico container due > > to it's underlying philosophy and poor documentation. I have used and > > been more intrigued by Spring and HiveMind. > > I've worked with just about every IoC framework currently available. > Each has its pros and cons. I like Pico simply because it's so small > and simple, but I can understand how everyone has their favorites. > > A DAO Framework is really just a specialized IoC container. I wrote an > article about this last year: > > http://www.jadetower.org/muses/archives/000080.html > > The advantage of extending and branding one as a DAO framework, I feel, > is that you can target a small and easily comprehensible application of > IoC and make a real difference in the quality of the code being written. > > -- > jaaron >
