Actually, the iBATIS DAO stuff works well with darn near any data access technology - sqlmaps, hibernate, jdbc, and about 5-6 more "out-of-the-box", so don't think that using the iBATIS DAO means you have to use iBATIS SQL Maps - they are very seperate tools.
What it does is similar to what you are describing - it creates a Map of DAO implementations that are keyed by the interfaces for them. One assumption that it does make is that the DAO implementations are thread-safe. It will also allow you to use the implementation as the key, but IMO this is not the best practice. Anyway, you can define an AccountDao interface with the basic CRUD operations, then implement that interface using any data access technology you prefer. Then you use the iBATIS DaoManager to get (shared) instances of those DAO classes. It will also help manage transactions, too. Larry On 9/1/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > As Leon said, there probably isn't any one "right" answer, although I > think it's fair to say that best practices is as Leon says, to *not* > create a DAO per service method. > > What I tend to do, and I'm not claiming this is any more right than > anything else, is to have a DAO factory where I get my DAOs from. It is > the factory's responsibility to get a database connection from the pool > and hand it off to the DAO. In this way I can have a single factory and > get multiple DAOs from it, each sharing the same database connection. > The factory I instantiate for each request, so if I use 10 DAOs during a > single request, it's still only a single database connection. > > Using something like iBatis or Hibernate would in effect take the place > of the factory and should deal with these concerns for you, but I have > not yet used either product in a production app, I've always done it > myself (getting away from that!). > > Frank > > Leon Rosenberg wrote: > > On Wed, 2005-08-31 at 21:19 -0700, Paul Benedict wrote: > > > >>Hey guys. > >> > >>I have alot of service objects called from Struts, and > >>each have a good deal of service methods. Service > >>methods mainly do business logic and talk to DAO > >>objects. > >> > >>Question: > >>I've taken the approach of service methods having the > >>responsibility of instantiating DAO objects locally > >>and using them. Is this correct? Or should I > >>instantiate all the DAO objects that could ever be > >>needed in my service constructor, and use them as > >>instance variables? > >> > >>Or is there a better design? > > > > > > Hi, > > > > design is always the matter of the desired functionality, so it's hard > > to say what is best for you without knowing your business goals. > > > > But what can be said for sure, is, that instantiating DAOs locally on > > each call is a waste of ressources, since each new DAO will probably > > create a new connection to the db. > > > > Having one instance per "service" is generelly better, but you must keep > > an eye on synchronization and concurrency. > > > > regards > > Leon > > > > > >>Thanks! > >> > >> > >> > >>____________________________________________________ > >>Start your day with Yahoo! - make it your home page > >>http://www.yahoo.com/r/hs > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
