That makes perfectly good sense, I think. What should be happening is (assuming I went the aspect route here) the aspect doesn't do the work, a core business object does the work and the aspect just knows about that object. The aspect passes information to the core business object, that object returns back to the aspect its validation decisions and the aspect handles that accordingly. The difference being from what I originally said was that the aspect itself wouldn't be enforcing these business rules instead of a core business object making those decisions.

So I think the overall answer is aspects are a valid method of enforcing the limitations but the limitation logic itself should exist outside of that aspect.

Adam
On 7/5/06, Dave Ross <[EMAIL PROTECTED]> wrote:
YES, your core business objects should be aware of the limitations.
Aspects are not part of your business model, and don't care about
rules and such (or at least they shouldn't!).

So, if you want to intercept method calls to perform validation,
that's a perfectly acceptable use of AOP. The important part is the
aspect itself doesn't do the validation - the aspect sees a detail
item coming in, and either calls validate() on it or passes it to some
validation service or rules engine or however you build your
application. Programming an aspect in this manner allows you to reuse
the validation/rule-enforcement business logic elsewhere in a more
direct fashion. The aspect just gives you a *different* way to weave
things together.

Does that help?

----------------------------------------------------------
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]

Reply via email to