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
Please forgive me
for sending this to the list, but I'm at wit's end trying to get one of my
accounts unsubscribed.
I sent this message to the admin a couple
weeks ago, and haven't gotten any
response.About an hour ago, I tried
to send a message from the account I'm trying to get
Hi Dave,
Interesting. I'd always though of AOP as primarily a tool for increasing
cohesion and DRY by pulling out cross cutting concerns. 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
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
Hi Dave,
I guess that is the distinction - between the business rules (which are part
of the model) and the process of initiating them (which might sometimes be
best implemented using aspects). Cool!
Best Wishes,
Peter
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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
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
I will be out of the New York office on July 6, 2006. If you need to contact
us, please call Sabrina @ 212.691.1134 x 25
Thanks,
Ben
--
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org with the words
Title: Message
Hi
Adam/Dave,
IKNEW 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 -
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
Hi Dave,
Just to clarify, I'm taking positions to understand the heuristics everyone
is using. As you said, we don't have the details and the truth is that the
answer is usually it depends!
The big take away for me is that AOP *could* be used to handle variability
across software product lines
I also think it's important to think about where and how AOP is
commonly applied to understand what sorts of uses are appropriate.
Most commonly you see containers like Spring/ColdSpring managing
stateless infrastructure components like DAOs or Services using the
Singleton pattern. It is less
12 matches
Mail list logo
