Hi Jason,
Firstly, I agree 100% with "it depends". There is no right answer
for all
cases. Many applications will never need editing of large
collections of
objects, so the bean approach will be the best approach.
Secondly, duh - good point. 1 object and load 2000 times does make
a bunch
more sense. If I need to do this, at least I now have a better
approach!!!
I associate core validations, transformations and calculations
with entities
(if a user email address is always required, I put that rule in
the model).
I also allow for association of validations, transformations and
calculations to specific actions (so a specific form may not
require a
password or an import may run a custom validation). In that way,
unchanging
rules are always enforced and context specific rules can easily be
managed.
To keep encapsulation, I actually just allow actions to extend the
base list
of calculations, transformations and/or validations required for a
given
call, and have entity specific calculation, transformation and
validation
cfc's which store the actual methods and extend base calculation,
transformation and validation cfcs so it is easy to find all of the
validation code in a project.
Best of luck with the refactoring - let us know how it works out!
Best Wishes,
Peter
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf
Of Jason Daiger
Sent: Tuesday, June 13, 2006 5:19 PM
To: [email protected]
Subject: RE: [CFCDev] Model or View?
>>Only if all of your validation is against single objects or
manageably
small collections of objects. What happens if you want to import a
large
number of >>users - perhaps using an uploaded csv file?
Peter I'd have to agree with your recommendation to remove the
validation
from the object. However, like most answers to IT questions 'it
depends'.
Validation w/in an object seems perfectly acceptiable based on the
business
requirements. As the business requirements expand to include
things like a
mass data load then it might be necessary to refactor the code and
pull the
validation out. Until that becomes a requirement, validation w/in
the bean
seems like a great place to start.
>>Assuming you implement that using CF (which is still plausible for
>>that
size of data set), how do you
>>validate 2000 email addresses? I've never tried to create a
collection
>>of
2000 objects, but I'm guessing it wouldn't perform all that well.
Why would you create 2000 objects? If needed simply create 1
object and
then clear and load that 1 object as needed to process the CSV
file. That's
minimal overhead with the same gain. Also from my experience data
imports
almost always have custom rules. You might need to remove validation
completely or partially or not at all which is why I'm proceeding
with the
plan to move the validation out of the bean and into the separate
area.
The biggest learning experience for me from this post is the
refactor piece.
I'm looking at refactoring 1 portion of my application out but the
rest
should remain the same and hence remain unchanged. Hopefully it
works as
well in practice as it has in my head up to now.
-Jason
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf
Of Peter Bell
Sent: Tuesday, June 13, 2006 3:59 PM
To: [email protected]
Subject: RE: [CFCDev] Model or View?
Nice to see a posting that isn't spam!!!
RADEMAKERS Tanguy said:
- On the one hand, you have a type of format checking that's
essentially
about type safety, and that operates on single fields. If you have
an object
that exposes an "email address" field, you expect that field (if it's
populated) to hold a syntactically valid email address, not just
any old
string (i.e. an email address is a string, but a string is not an
email
address). This kind of checking belongs in an object.
Only if all of your validation is against single objects or
manageably small
collections of objects. What happens if you want to import a large
number of
users - perhaps using an uploaded csv file? Assuming you implement
that
using CF (which is still plausible for that size of data set), how
do you
validate 2000 email addresses? I've never tried to create a
collection of
2000 objects, but I'm guessing it wouldn't perform all that well.
That
leaves you with duplicating the code in both the object and a
service layer.
That's the only thing I can't square with building validation into
an object
- how it handles use cases where you want to deal with larger
collections of
data that don't make sense to instantiate as a collection of objects.
As with most things OO, I'm probably missing something obvious :->
Any thoughts?
Best Wishes,
Peter
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf
Of RADEMAKERS Tanguy
Sent: Tuesday, June 13, 2006 1:32 PM
To: [email protected]
Subject: RE: [CFCDev] Model or View?
>What i do, cuz i'm a little intellectually lazy, like Ray, is to
place
a validate
>function in my bean. Others abstract the validation to a separate
object, but i
>prefer having it in one package. It's just a little easier for me to
see what's
>going on.
I think there are two different kinds of validation:
- On the one hand, you have a type of format checking that's
essentially
about type safety, and that operates on single fields. If you have
an object
that exposes an "email address" field, you expect that field (if it's
populated) to hold a syntactically valid email address, not just
any old
string (i.e. an email address is a string, but a string is not an
email
address). This kind of checking belongs in an object.
- On the other hand, you have what's commonly referred to as
business rules,
which can operate on one or more fields. The email address field
might be
mandatory, or it might be restricted to email addresses from a
certain
domain, or whatever. This kind of checking belongs outside the
object -
usually in its own object, which accepts an instance of the object
to be
checked as an input parameter.
I think it's a good idea to separate the two this way because
business rules
tend to be both more changeable over time and can also be context
sensitive,
whereas type or format checkers tend to be pretty stable. Bob from
marketing
might change his mind every two weeks as to whether the email
field should
be mandatory or not, or come up with all kinds of context related
exceptions
like "normal users can only enter email addresses from the same
domain as
their email address but administrators can enter email addresses
from any
domain, or not enter an email address at all if they want", but what
constitutes a syntactically valid email address is not likely to
change that
much.
just my 0.02$
/t
----------------------------------------------------------
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]
----------------------------------------------------------
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]
