I don't think it's an opinion limited to myself and iBATIS... Gavin King and Christian Bauer of Hibernate fame have also spoken out against them in the past. I think a lot of people are coming to the conclusion that MVC + Service + Persistence is enough layers. :-)
I couldn't find Gavin's original post (from many years ago) on the subject, but I believe this thread references it and might offer some shared insight: http://forum.springsource.org/showthread.php?t=64147 That said, you did point out at least one case that is still certainly relevant... if I were to build an app with JDBC today, I'd definitely put that code in a nice little package. However, I wouldn't call it a DAO anymore, and would probably call it a Mapper. Here's how I distinguish the two: Mappers: To me a Mapper says "Take this object and store it somewhere, mapping the fields (i.e. state) of the object to some other structure, be it a relational model, an XML file, a DOD, Amazon S3... whatever, and stop there." DAOs: DAOs are more abstract that Mappers, and usually are broader in scope as well. They may take a complex object, save all of its parts and even call out to other DAOs (although I always made a rule to avoid that). DAO frameworks always had a repository, factory or DI container that managed them. Furthermore, the DAO framework also often abstracted the transaction control system as well (whereas a Mapper would be unaware of the transaction). So I see a DAO framework as a broader scoped an abstraction layer in the software architecture, with interfaces, factories and transactions in all their glory. I see Mappers as more of a fine grained implementation layer that is far simpler and narrower in scope. Clinton On Sun, Aug 30, 2009 at 9:02 PM, Carlos Pita <carlosjosep...@gmail.com>wrote: > > DAOs have become the boilerplate in my opinion. > > > > ActionBean(Stripes) > Service(POJO) > Mapper(iBATIS) > > Interesting. I dare to say that your point of view is clearly influenced by > your > use of ibatis, isn't it? I can hardly imagine programming a services tier > with > verbose jdbc or obscure hql embedded. ibatis gets rid of most of the > persistence concerns encapsulating them inside the mapper (I mean, the > xml one). So it's logical to (learn to) stop worrying and love the mapper. > And to conclude that DAOs are boilerplate. > > > I don't think you'd have to patch the code... You can implement your own > > SqlSessionFactory and SqlSession instances, decorated with your > > On second thought a completely external proxy that has access to the > configuration and sqlSession is more than enough for my needs. > The api exposed by ibatis will suffice, there's no need for > extension points. MapperMethod will be a valuable guideline for the > implementation. I really don't care about session.getMapper() returning > different proxies according to the enhance setting state or > things like that. I'm grown enough to instantiate my own proxies :). > > Anyway I will let the idea of discarding daos mature for a while > before putting hands to work. > > Thanks again. > > Best regards > -- > Carlos > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org > For additional commands, e-mail: user-java-h...@ibatis.apache.org > >
