What we do is take all of our /DAO/Model 'stuff' and package it up into its own jar file that is then included in any projects that require it. This allows us to A) Version our data systems without impacting the apps using them (mostly) B) Gives us a unified data layer for all of our applications C) Allows us to distribute a data 'api' to internal and external parties D) keeps things clean E) reuse our data layer in web(wicket/servlets), desktop (swing) and command line(cron etc) apps
Practically for us this manifests as a unique eclipse project that exists just for data access. Its package is, for example, net.pnc.model.* and net.pnc.model.dao. Devs put the maven dependancy in and their app magically is data-enabled. Client apps just work on the model via the DAO which retrieves and saves javabeans to and from the database etc. Its probably very primitive, violates a lot of patterns and sucks for many reasons but its great for us. We also use Cayenne (shameless plug). Its really easy to work with for someone not comfortable with Hibernate and in a wicket context follows some of the same ethics (convention vs configuration, CPUs are faster then your app etc). Your Mileage May Vary, this has been sustainable for us. John- On Tue, Aug 4, 2009 at 12:46 PM, Dane Laverty <danelave...@gmail.com> wrote: > > - In app v. session, one thing I've read in several places is "never put > your DAOs in your application". I'm sure that's great advice, but I don't > know why. From my perspective, a DAO is exactly the kind of thing I would > put in the application -- it's the same for all users, and it would be > really handy to have there. The phonebook app, OTOH, puts DAOs directly in > the pages, so that's the model I'm following for my current application. >
