And just to add...
What about other methods such as isValidCustomerID() - you clearly can't
have generic validation because some properties are integers, others are
strings etc... So you would be in a situation where you GET generically, but
Validate specifically:
- Get('CustomerID')
- isValidCustomerID()
Its not nice.
Baz
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Jason Daiger
Sent: Thursday, January 19, 2006 2:41 PM
To: [email protected]
Subject: Re: [CFCDev] Bean and CFC question
The only problems I have with method #2 is the definition of the
'contract' between the bean and the database layer is very loose. I've
thought about the same approach for the very same reason but I didn't
like that users of the bean didn't know exactly what it could contain
(since it can contain any key/value pair) and what type of data it was
storing. It just seems this approach enforces the domain model as well
(to me that is). Thus the contract b/w the data object using the bean is
way more relaxed and not as obvious. I prefer method 1 simply b/c it is
more clear what a bean owns and thus makes the contract b/w bean and
data access more apparent.
-Jason
Nick Han wrote:
>I like the use of beans as a bridge to transport data between the
>presentation layer (forms) and business objects, which do all the
>database interactions. Constructing beans can be a repetitive and
>time-consuming task, so lately I have been toying around with a
>different transfer object that acts like a bean, but it is easier to
>build, add on, and maintain. I would like your opinions on it and
>whether it is a good or bad.
>
>Instead of writing a bean that has getters and setters and will
>interface like this:
>
>
><cfset objFilter=CreateObject("component","reportFilter").init(dsn)>
>
>Method #1
>
><cfset objFilter.setFirstname="John">
><cfset objFilter.setLastName="Doe">
>
>I then pass this objFilter into my business object. Inside the business
>object, the values in the filter object will be accessed like this:
>
>Arguments.objFilter.getFirstName();
>Arguments.objFilter.getLastName();
>
>Method #2
>
>I have been toying with this method:
>
><cfset objFilter.add('firstname','John')>
><cfset objFilter.add('lastname','Doe')>
>
>Inside my business object, I would access the values of the objFilter
>like this:
>
>Arguments.objFilter.getValue('lastName')
>Arguments.objFilter.getValue('firstname')
>
>The advantage I see in Method 2 is that as the business object requires
>additional filter parameters, the objFilter object doesn't require the
>maintenance of adding more getters or setters.
>
>Any thought on the good or bad on Method #2 is appreciated. Thanks.
>
>
>----------------------------------------------------------
>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]
>
>
>.
>
>
>
--
Jason Danger
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]
