Re: [CFCDev] DAO vs. Gateway?

[Jason Daiger]

Peter, This is the same internal debate I had about 4 months ago.  I had been reading the Core J2EE Design Patterns book, had just attended the Fusebox/Frameworks conference and was looking at other online discussions as well.  I decided to follow the J2EE Design approach and put all my persistant methods into the DAO object and forgo the Gateway.  In the end it's a matter of preference and how much separation you desire in your application.  I choose the DAO option b/c I wanted all my SQL calls in 1 spot.  I just recently reaped the rewards of this decision.  I was working w/ MS SQL had several DAO's against it, then ported a portion of the application to MS Access and then ported the MS Access to MySQL.  Why the hop skip and jump b/w db's is another story but the moral is, I only had to change a few lines of code w/in my DAO objects and everything worked as expected.  In the end I just prefer all my SQL in 1 file instead of 2 which is why no Gateway. -Jason 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 -- Jason Daiger URL: www.jdaiger.com EML: [EMAIL PROTECTED] ---------------------------------------------------------- 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