Ah I see!, I hadn't considered the ramifications of the more complex validation, like you say, those that involve cross checks between objects and database calls, these would certainly be more difficult to implement using AOP or a generic class. I understand your thinking here completely.
I have just started reading an article about a Validation framework built in JAVA which uses Spring and AOP, the idea being that you can implement a blanket validation process for these more 'trivial' tasks and data comparisons using AOP, which helps save development time, and then in the underlying model and business logic you can manually build these more complex validation checks. I think that building a system which allows space for both may work well, as it leverages the power of the framework to free up time doing the more trivial tasks and at least ensures a basic level of volition across the entire application, yet allows you to then extend that with non AOP business logic validation for the more complex data? Thanks again Brian, I hadn't considered those more complex validation problems, Rob -----Original Message----- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: 08 October 2007 17:05 To: CF-Talk Subject: Re: AOP in ColdSpring and ModelGlue On 10/8/07, Robert Rawlins - Think Blue <[EMAIL PROTECTED]> wrote: > > Now I agree that you should really be validating every business object, > however I'm thinking about building this proxy layer between the > controller > and the model, and all data coming from the controller is generally user > generated, from a form or url, and in my mind this is perhaps the best > place > to validate the data, before it actually gets into the business objects > rather than once its arrived. I think this is where your approach will break down. I would disagree that the best place to validate the data is before it gets to the business object. In fact, for anything other than the most trivial validation, this can get very convoluted. Because what you really want to validate isn't the data itself, it's the state of the business object. So it's easy to "pre-validate" data based on very simple rules like "this must not be empty" or "this must be numeric". But any complex property of the object requires actually using the business logic in the object itself to determine whether something is valid or not. What if I want to validate that the user's user name is unique (via a call to a data access object that is composed into the User object)? What if I want to validate that an Order is only valid if the associated customer has no outstanding invoices (order has a customer via composition)? Unless you're going to duplicate (or move) the logic to do this out of the actual business object, which I think would probably be a bad idea, trying to validate the data *before* it gets to the business object in question seems to rapidly hit a dead end. This is especially true if you are going the route of "rich business objects" that actually have behavior instead of being nothing but "dumb" beans (properties with getters and setters). All that said, it still doesn't mean you couldn't do this with AOP. It just means I would look at having the advice get the object from the service and then pass it into a validator. When I do validation, I usually do something like this from within my business object: getValidator().validate(this), which means the validator has a reference to the actual object itself and can call methods on it to validate it, rather than relying on nothing but the instance data which has no behavior at all. It's fairly easy to define rules that all validators can use (along with custom rules for specific situations), but again, I personally wouldn't try doing it with AOP. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Download the latest ColdFusion 8 utilities including Report Builder, plug-ins for Eclipse and Dreamweaver updates. http;//www.adobe.com/cfusion/entitlement/index.cfm?e=labs%5adobecf8%5Fbeta Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290568 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
