"If you do that, a problem arises if you want to re-use (part of) your
domain classes library for a different
application. Using AOP this can be solved."
I would sooner see it reused through other mechanisms than applying runtime
aspects. There is the "too much magic" problem to deal with as well as the
problem of finding out exactly where behavior is coming from. The thing that
really kills me about using AOP on business logic (atleast runtime woven
AOP) is the fact that you will tend to have a 1-1 match of advice to aspects
.. what is the point of encapsulating something into an aspect if it is only
used once. You have added a whole lot of complexity (runtime proxies)
without getting much in return.
Nice examples, though do you really need AOP for this or is a
strategy pattern also a way to do this? IMHO you don't need
AOP for this.
Strategy pattern for which?
On 6/1/06, Frans Bouma <[EMAIL PROTECTED]> wrote:
> I _*cannot_* recommend enough to *_not_* put most business
> logic into aspects.
Isn't that the stone-age old discussion about:
having BL code inside domain classes vs. having BL code outside
domain classes?
> Business logic is generally not a cross cutting concern. All
> you end up doing in adding a huge level of complexity to your
> domain. There are better less expensive ways of doing this
> basic inheritance and composition are great, but the strategy
> and specification patterns also shoot to the top of the list.
true, I use the strategy pattern as well to inject BL / validation
code inside domain objects, so trust me I'm on your side,
but that doesn't mean it's the only POV on the matter. For example the DDD
community focusses heavily on having BL code inside
domain classes. If you do that, a problem arises if you want to re-use
(part of) your domain classes library for a different
application. Using AOP this can be solved.
> A more accepted use of aspects is to address cross cutting
> concerns. I personally do not like to go through the usual
> logging example as it is a trivial example, I instead prefer
> to use caching and the automation of transactions within an
> object graph.
>
[...]
Nice examples, though do you really need AOP for this or is a
strategy pattern also a way to do this? IMHO you don't need
AOP for this.
FB
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
--
If knowledge can create problems, it is not through ignorance that we can
solve them.
Isaac Asimov
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
