Interesting. I'd always though of AOP as primarily a tool for increasing cohesion and DRY by pulling out cross cutting concerns.
Not sure where I suggested that it isn't. If you see *the initiation* of validation/business-rule enforcement as a cross-cutting concern in your application, then AOP is *one* solution to tackling that problem. I might validate business objects at the service layer or possibly the database layer, but if you were adding functionality after the fact or needed to quickly apply a new rule engine across your codebase, AOP is a way to do that without massive changes in your code. Basically, you can perform validation "at a layer" or use AOP to perform validation "in between layers".
What you're suggesting is that it is also an appropriate way of effectively dropping a publish/subscribe pattern inside your business model where you could look at all method calls as published events and point cuts subscribing an aspect to matching method calls.
I guess you could look at it that way - but to me you're just re-describing how AOP works. We've already got enough confusing concepts and terminology - no need to further muddy up the idea :)
Firstly, do you think this is a good way to go or just a "fix"? If it is a "good" way to go, how far would you take it? Would you look at this as a model for implementing variability across applications by putting everything that varies (e.g. shipping rules, tax rules, checkout rules, etc.) into aspects and just using a different set of aspects to customize one application from another?
Again - ASPECTS ARE NOT PART OF YOUR MODEL. Sorry to yell that, but in no way shape or form should you have a TaxRuleValidationAspect or a ShippingValidationAspect. Appying rules and validation is part of your model - aspects allow you to modify the programs flow so you could perform this validation before, after, or during a method call, but you'd have to address the reasons "why" you want to do that. HTH, 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]
