On 7/5/06, Peter Bell <[EMAIL PROTECTED]> wrote:
I KNEW there was something bothering me about this solution and I couldn't figure out what it was. I just figured it out. This is not a cross cutting concern!!!
ok. Except no code has really been posted, no detailed specs dicussed. What I'm trying to say is that you can't be so blatant with the "is" and "is not" in a purely hypothetical situation. Trust me, initiating validation can sure as hell be a cross cutting concern if you've got: <cfif not arguments.someObject.isValid()> <cfthrow type="invalid object exception"/> </cfif> in more than one component (I'd venture to guess that a lot of systems have this type of code sprinkled throughout).
I agree that the business rules themselves would be in a Rules class somewhere within the model - just as any really sophisticated logging or security code would simply be called by an aspect - not implemented within it. However, the whole point of cross cutting concerns is that they are relevant to multiple classes (cutting across multiple class files). If you just want to extend a single class a simple concrete decorator would be more appropriate.
The example above should illustrate that the act of validating ANY object is indeed relevant to more than one class. Again, there isn't a ShoppingCartValidatorAspect or a TransactionDetailValidatorAspect - you would write a completely generic aspect.
Adam, how many classes do the business rules really touch? It seems to me that it is primarily affecting the cart. If so, I'm not sure I'd consider it to be a cross cutting concern. Dave, as a rule of thumb, how many components would you say an aspect should potentially be relevant to for it to be a cross cutting concern? Almost by definition I'd say it has to be at least two and whether it's worth going the AOP route would then depend if you were using aspects and/or an AOP framework (like ColdSpring) already. I probably wouldn't add ColdSpring just to save two or three concrete decorators (although to be fair I can't conceive of building an application without using ColdSpring now I've seen what it can do for me just in terms of dependency injection).
More than one. Two. Peter, you've got to understand that Adam asked if this would be an appropriate use of AOP. My answer is "yes". He did not ask, "is AOP better than another approach to solving this problem?". My answer would be "possibly". So much depends on your environment, existing codebase/architecture, and the nature of the specific goal you're trying to accomplish. If I implemented validation on several of my primary business objects and then wanted to stay away from touching other layers of my application, I would weave in calls to those validation routines using AOP. If I implemented a generic rules engine that I wanted to weave into my application, I would probably weave that in via AOP. Speaking of generic rule engines, just as an aside, Drools, a rules engine that is part of JBOSS, is implemented using lot of AOP *and* can be implemented via. aspects, for example shown here: http://today.java.net/pub/a/today/2005/11/08/implementing-validation-rules-with-aspects.html?page=last -Dave ---------------------------------------------------------- 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]
