> Sun's definition of DAO is very broad. But it's also a perfectly legit one, probably moreso that your definition (which also happens to be the one I use). A gateway is just as much a DAO as what we term a DAO, since it's sole purpose is to interact with a persistant store in a way that abstracts the actual store from calling code (i.e. an object for data access).
I prefer to think of things more along the lines of the public interfaces of entity EJBs. You have the "home", which provides the ability to create an entity, fetch an entity by primary key, or perform searching methods for returning collections of entities, or collections of information about entities. Contrast that with the actual entity object, which has control over persistance of it's own data members. With CMP, the container is writing all your data access code for you (and who knows how many objects it's using), but there are two very distinct types: the stuff to persist a single entity, and the stuff to select one or more entities (or their fields). To return to gateways vs. DAOs. I use the term gateway to refer to the object with those select methods, and the term DAO for the entity-specific persitance implementation. The analogy is definitely not watertight, but its definitely good enough for broad conceptual thought. cheers, barneyb On Mon, 15 Nov 2004 21:22:49 -0800, Sean Corfield <[EMAIL PROTECTED]> wrote: > On Mon, 15 Nov 2004 20:03:34 -0600, Joe Ferraro <[EMAIL PROTECTED]> wrote: > > I'm confused about your comments here Sean. Where can I find out more > > information about a data gateway? > > Martin Fowler's Patterns for Enterprise Application Architecture (or > whatever it's actually called) is a really good place to read about > this stuff. > > Sun's definition of DAO is very broad. > > > -- > Sean A Corfield -- http://www.corfield.org/ -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/blog/ I currently have 0 GMail invites for the taking ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
