exactly!
On 7/5/06, Adam Haskell <[EMAIL PROTECTED]> wrote:
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]
----------------------------------------------------------
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]
