Re: [CFCDev] DAO vs. Gateway?

[Chris Scott]

I think best practices may be a bit hard to define in this area. I think you're right on with your explanation of wrapping the implementation of persistence in a service layer, like a facade for the DAO and possibly Gateway objects. I'm not too sure why you would add another facade in the form of a Gateway object that simply forwards method invocations off to the DAO, so I would say either separate list type methods into a Gateway, or use a combined DAO. Personally I like to split the data access tier into DAOs and Gateways when writing ColdFusion, but for some reason, and I have no honest explanation for this, when writing Java, I have fallen into writing one DAO per domain object that handles both CRUD methods and list methods. I think that may have spawned from wanting to look at a single interface for each domain object in uml.  -Chris On Feb 27, 2006, at 4:17 PM, Peter Bell wrote: Another simple question. I understand that "best practice" for non-trivial applications is often to have entityService wrapping entityGateway and entityDAO with the DAO wrapping persistence implementation spercific code (e.g. SQL commands or write to file for XML) for single entities and the Gateway providing access to multiple records.   Two questions: - Do you usually include SQL in the gateway or ask the gateway to wrap list based methods in the DAO to fully encapsulate knowledge about the persistence layer? - Secondly, could you give a sense of a use case where there is value in having a separate Gateway as opposed to just having a simple entityManager (with getByID, getList, save, delete and all other required methods) as the service layer speaking directly to entityDAO which handles all persistent access and can be called using abstract factory to support n-persistence options? I'm just trying to understand what is philisophically different between persisting n objects and persisting one.   Any thoughts appreciated. Best Wishes, Peter   ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org