Cliff,
Thanks for the suggested readings. It did help and has me thinking back to
some earlier OO objects I used for client server apps I wrote several years
ago. (BTW that did give me another approach idea so thanks for jogging my
memory) I believe Fowler would say those objects were more full featured on
several fronts but also very poorly designed on others. Unfortunately even
that domain model (although we didn't call it that back then) was much
closer to a 1 to 1 mapping w/ the database. It seems with the numerous ORM
frameworks popping up to help speed development the trend is certainly
leaning toward the Anemic Domain Model. Trying to wade through the
differences, pros and cons of the domain model design and all the other OO
design issues and patterns can almost leave one paralyzed w/ thought. Which
leads me to believe this 'paralyzed thought' could be partly to blame for
OO designed applications still having roughly the same success/failure rate
as non OO designed applications. Which as of 2 years ago was still around
the 50% success rate.
So what to do? Well, my vote is to throw some mud on the wall and see if it
makes a picture. If it doesn't, regroup and try again until you figure out
how to make it work for that application. I try to keep two of the eXtreme
Programming practices in mind: Keep it simple and only worry about that
task. So in my case, I've decided the validation rules vary so much between
clients adding them to the domain is not a viable solution and hence must be
pulled out of the domain model. If removing validation from my domain model
means it becomes anemic, oh well. I know my clients do not care if the
domain model is anemic or not. They just care whether it works.
-Jason
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of Cliff Meyers
Sent: Wednesday, June 14, 2006 4:40 PM
To: [email protected]
Subject: Re: [CFCDev] Model or View?
I would caution against pulling validation out of the domain model entirely,
since it could lead to Fowler's "Anemic Domain Model"
antipattern:
http://www.martinfowler.com/bliki/AnemicDomainModel.html
"It's also worth emphasizing that putting behavior into the domain objects
should not contradict the solid approach of using layering to separate
domain logic from persistence and presentation responsibilities. The logic
that should be in a domain object is domain logic - validations,
calculations, business rules - whatever you like to call it. (There are
cases when you make an argument for putting data source or presentation
logic in a domain object, but that's orthogonal to my view of anemia.)"
Since many validations are commonly re-used I think it might be better to
build a validation library that the domain objects directly leverage instead
of refactoring the code out into separate "validator"
classes. Fowler talks about the simple but powerful concept of "Contextual
Validation" here:
http://www.martinfowler.com/bliki/ContextualValidation.html
HTH,
-Cliff
On 6/13/06, Peter Bell <[EMAIL PROTECTED]> wrote:
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]
----------------------------------------------------------
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]
