Hi
Adam/Dave,
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!!!
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.
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).
Am I
missing something guys?
Also,
for all you pattern guru's out there, are there any other approaches we should
be considering?
Best
Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----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.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Haskell
Sent: Wednesday, July 05, 2006 5:43 PM
To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Aspect or not?
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 cfcdev@cfczone.org 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/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
