> 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® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
