This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
[EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] 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/[email protected]
Reporting-MTA: dns;ci-mail1.CI.conservation.org
Received-From-MTA: dns;cmta1.cgnet.com
Arrival-Date: Thu, 2 Mar 2006 00:27:59 -0500
Final-Recipient: rfc822;[email protected]
Action: failed
Status: 5.1.1
--- Begin Message ---
i
Content-Type: multipart/alternative;
boundary="------------040408040403080403020008"
X-Virus-Scanned: by Barracuda Spam Firewall at safesecureweb.com
Precedence: list
Return-Path: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
Subject: [CFCDev] (No Subject)
Reply-To: [email protected]
This is a multi-part message in MIME format.
--------------040408040403080403020008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
My .02 on the DAO's getting huge is the same response given when Model
Glue folks that complain the configuration file that is too long. Use a
good editor and you probably won't even notice the size. For me
managing 2 small files is a bigger pain than 1 large file. Also, I'm
not making any comments on the editor folks are using (obviously since I
have no idea what people are using) but I've found the code collapse
w/in Eclipse eliminates the big file concern for me. Thus I'm left with
the 'keep track of 1 or 2 files' issue and I simply choose 1 approach.
I have yet to hear of a design reason why the 2 file approach is better
or why a 1 file approach would break the design pattern both approaches
strive to achieve. In the end, it seems like personal preference. Now
if someone tells me the 1file approach breaks down because of X or
breaks a design pattern b/c of Y then I'm all ears. Until then, it's 1
file for me.
Peter J. Farrell wrote:
> Kurt Wiersma said the following on 3/1/2006 12:52 PM:
>
>> Like Chris Scott, I have found that the Java convention seems to be
>> having all the code in a DAO class. In my CF apps I have found I
>> really like having the gateway separate because in Java I have found
>> my DAOs get huge with all the different methods that sometimes have to
>> be added for reporting purposes.
>>
>> --Kurt
>>
> Ditto! Although I don't do any Java developing, I have found that DAO
> classes with everything gets unwieldy after a bit of time. Also, I like
> the idea of having my DAO access single records, while the Gateway is
> one or more. Secondly, typically my DAOs return populated beans while
> the Gateways returns cf query objects.
>
> .Peter
>
>
--
Jason Daiger
URL: www.jdaiger.com
EML: [EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] 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/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] 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/[email protected]
--------------040408040403080403020008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
My .02 on the DAO's getting huge is the same response given when Model
Glue folks that complain the configuration file that is too long. Use a
good editor and you probably won't even notice the size. For me
managing 2 small files is a bigger pain than 1 large file. Also, I'm
not making any comments on the editor folks are using (obviously since
I have no idea what people are using) but I've found the code collapse
w/in Eclipse eliminates the big file concern for me. Thus I'm left with
the 'keep track of 1 or 2 files' issue and I simply choose 1 approach.
I have yet to hear of a design reason why the 2 file approach is better
or why a 1 file approach would break the design pattern both approaches
strive to achieve. In the end, it seems like personal preference.
Now
if someone tells me the 1file approach breaks down because of X or
breaks a design pattern b/c of Y then I'm all ears. Until then, it's 1
file for me.<br>
<br>
<br>
<br>
Peter J. Farrell wrote:
<blockquote cite="[EMAIL PROTECTED]" type="cite">
<pre wrap="">Kurt Wiersma said the following on 3/1/2006 12:52 PM:
</pre>
<blockquote type="cite">
<pre wrap="">Like Chris Scott, I have found that the Java convention seems
to be
having all the code in a DAO class. In my CF apps I have found I
really like having the gateway separate because in Java I have found
my DAOs get huge with all the different methods that sometimes have to
be added for reporting purposes.
--Kurt
</pre>
</blockquote>
<pre wrap=""><!---->Ditto! Although I don't do any Java developing, I have
found that DAO
classes with everything gets unwieldy after a bit of time. Also, I like
the idea of having my DAO access single records, while the Gateway is
one or more. Secondly, typically my DAOs return populated beans while
the Gateways returns cf query objects.
.Peter
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Jason Daiger
URL: <a class="moz-txt-link-abbreviated"
href="http://www.jdaiger.com";>www.jdaiger.com</a>
EML: <a class="moz-txt-link-abbreviated" href="mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]</a></pre>
</body>
</html>
----------------------------------------------------------<BR>You are
subscribed to cfcdev. To unsubscribe, send an email to [email protected] with
the words 'unsubscribe cfcdev' as the subject of the email.<BR><BR>CFCDev is
run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).<BR><BR>An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------<BR>You are
subscribed to cfcdev. To unsubscribe, send an email to [email protected] with
the words 'unsubscribe cfcdev' as the subject of the email.<BR><BR>CFCDev is
run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).<BR><BR>An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
--------------040408040403080403020008--
--- End Message ---
