Hi Cliff, This is still something I'm trying to come to terms with. I've seen the references to the anaemic domain model and am trying to understand how to best go about arranging models.
Lets say you want to process a user registration form. Your controller packages up the input scope (form and URL variables) and calls a save method within the model. Should the controller call UserService.Save() or call UserFactory.getUser() (or Factory.get(User) using "any" returntype for Factory.get) and then call User.Load(INPUT_STRUCT) and User.Save()? If is calls UserService.Save(), would that do the save, or would that just encapsulate UserFactory.getUser(), User.Load(INPUT_STRUCT) and User.Save()? Any input appreciated! Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cliff Meyers Sent: Wednesday, June 14, 2006 4:40 PM To: CFCDev@cfczone.org 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: CFCDev@cfczone.org > 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: CFCDev@cfczone.org > 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: CFCDev@cfczone.org > 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 > 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 > > > > > > ---------------------------------------------------------- > 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 > > > ---------------------------------------------------------- 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
