I think we're talking about the same thing. Whatever you want to call it (DAO, persistence layer, mappers) it still accomplishes the same thing. Only your daos would know about JDO or JDBC so yes, the change is located in one place.
All I'm suggesting is that a dao helper framework is useful for implementing your dao classes. I've called mine "mappers" because they're used to map objects to a datastore and I think it reads better than an abbreviation like DAO; however, it's obvious that dao is more widely and immediately understood. My framework includes a JdbcMapper parent class for all mappers using JDBC as their persistence technology. This class reduces the amount of mundane jdbc code I need to write; if I would just learn JDO I could cut it down even more ;-). Dave >From: "James Higginbotham" <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >Subject: RE: [OT] RE: Persistence Framework Comparison? >Date: Fri, 4 Oct 2002 17:10:23 -0500 > > > > > -----Original Message----- > > From: David Graham [mailto:[EMAIL PROTECTED]] > > Sent: Friday, October 04, 2002 4:29 PM > > To: [EMAIL PROTECTED] > > Subject: [OT] RE: Persistence Framework Comparison? > > > > > > I think you missed the point. Yes, JDO lets you program to > > an interface > > with multiple vendors competing on implementations. But what > > if you don't > > want to use JDO? > >Hmm... Ok, understood - I guess it depends on how far your project >requires you to abstract from an O/R layer. I know things happen, but >man.. If you are using JDO and want to abstract from an abstraction, >where does it end? Anywho, I'm sure there are business or technical >requirements for this, or its primarily for risk mitigation. I'm not on >your project, so I have no say here ;) > > > > > This is a layer above all persistence frameworks (JDBC, JDO, > > EJB, OJB, etc.) > > that your application programs to. If you decide to change > > persistence > > frameworks, most of your code remains unchanged because it > > doesn't know > > which one you're using. > >Most of your code shouldn't care, only your DAOs, so the impact should >only be on the data access layer you provide for your models. That >shouldn't be a bad issue, since swapping out persistence frameworks >usually isn't hard but there are nuiances to every one. > > > > > I, and others, have rolled our own but I think it would be useful for > > Jakarta Commons to provide this framework (similar to their > > logging api). > >Maybe you should consider pitching it to Apache Commons or open it up on >Sourceforge and see if Apache or someone larger can manage it long term? > >Anyway, hope the abstraction works out for you on this. >James > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
