Edmund vs AOP
Thomas Messier
as far as the problems each can solve. Taking a simple example like
logging, if you wanted to log a certain event, with Edmund your logger
would subscribe to an event and once the event was dispatched the
logger would be notified and run whatever logging code is specified.
With AOP (and apologies for terminology here, not sure what the
correct terms are for everything), you could basically insert the
logging functionality before or after a function instead of
dispatching an event in it. Essentially, both seem to do the same
thing in different ways, they help keep code/components decoupled. So
in the example above, would it make more sense to use something like
Edmund or AOP? In my estimation, seems like Edmund would be great for
when you want to provide an API for another developer to run processes
when something important happens in the system, whereas for something
that's very system wide like logging, AOP would make more sense.
Thoughts?
David Long
Edmund would make great use for logging as you don't want the user to be effected by the logging function. I'm not too familiar with AOP, but I generally stick with Edmund or some other event based system when I am running interactions that don't involve the user (logging, tracking and interacting with other systems).
sent from my Android smart phone
--
You received this message because you are subscribed to the Google Groups "edmund-coldfusion" group.
To post to this group, send email to edmund-c...@googlegroups.com.
To unsubscribe from this group, send email to edmund-coldfus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/edmund-coldfusion?hl=en.
Sean Corfield
<thomas....@gmail.com> wrote:
> when something important happens in the system, whereas for something
> that's very system wide like logging, AOP would make more sense.
Whilst logging is often held up as the poster child for AOP, I'm not
really convinced it's the best solution because it's a dumb, automatic
solution. In other words, if you just want to log function calls, AOP
is fine. If you actually want to log specific operations, AOP is just
not "smart enough" to do that.
I've dabbled with AOP a few times for supposedly "good fit" scenarios
but have almost always backed off and used a different approach
because AOP isn't flexible enough.
YMMV.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Thomas Messier
Whilst logging is often held up as the poster child for AOP, I'm not
really convinced it's the best solution because it's a dumb, automatic
solution. In other words, if you just want to log function calls, AOP
is fine. If you actually want to log specific operations, AOP is just
not "smart enough" to do that.
Sean Corfield
<thomas....@gmail.com> wrote:
> Interesting, can you elaborate on that? I figured that, for example, if you
> have a service method to add a product, you could use AOP to run some
> operation to log the product addition after it's done. Wouldn't that count
> as logging a specific operation? I'm assuming that the very dumbed down
> examples we're dealing with may have me missing something?
Right, the "advice" you want to run here is very specific to the use
case - very specific to the business logic - so it isn't really a
cross-cutting concern at all and it would be much clearer in your code
to explicitly call the logging method from the product addition
method. Using AOP, you have your business logic (add the product and
log it for an audit trail) in two completely separate places, wired
together "automagically" by some outside agent.
With the event-driven approach, you would at least see some event
being fired from the "add product" point and it would (or should!) be
easy to see the full set of listeners that will respond to it. Caveat:
that supposes you follow reasonable patterns in your event-driven
architecture - I've seen horrendous hub'n'spoke event-driven messes
where a central piece of code fires all the events and the listeners
are scattered all over the place. That is just as bad as AOP :)
Does that help?
Thomas Messier
On Saturday, April 21, 2012 2:44:05 PM UTC-4, Sean Corfield wrote: