Title: Message
|
Hello
Chris and Jason,
Many
thanks for the great feedback. I'm going to start off with DAO only as one of my
design requirements is to support n-persistence methods and I'm in no rush to
create 2xn methods to support that! If anyone else has any compelling reasons
for separating the gateway from DAO I'd love the input!
Best
Wishes,
Peter
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
----------------------------------------------------------
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
|
