Showing posts with label AOP. Show all posts
Showing posts with label AOP. Show all posts

Wednesday, February 13, 2008

Domain Oriented Messages

Greg Young has a great post titled Mocks are a code smell.

As he explains the title is to grab your attention and although he does see mocking being overused, which is definitely my view and seemed to be the general feeling at the mocking session ALT.NET UK, the post itself covers a very interesting way of handling communication within the domain.


To be honest Greg's ideas and implementations of this pattern are more advanced than mine, and I know he uses it a lot more in his designs that I do, so I'm looking forward to reading his other posts on this topic.

Trying It Out - Start Simple

If you're daunted by the idea of going to a messaging approach then you could always start simple.

As an example I would say that what Greg is suggesting is just a more advanced version of the approach that I intend to use for dirty tracking within our domain. Messages are generated when domain events happen and these will be registered with a service that you get from a service locator.

This makes testing simple as you can just use a test spy (same approach as Greg seems to be using) but is also a design that I like in terms of lowering coupling.

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

Tuesday, February 05, 2008

AOP and the Domain - Aspects of Domain Model Management

Finally got round to reading Mats Helanders InfoQ post Aspects of Domain Model Management.

The article is very long, with a lot of content being around hacky solutions to the problems that the author is delaing with (attaching non-business logic to the domain).

I read all of the article but if you get bored you can skip most of the middle bit right up to Using "Aspect Oriented Programming".

The bit on proxies is interesting, if you're using NHibernate then you are already using the Infrastructural Proxy Subclass approach for lazy-loading (and collections) so you should be familiar with it. However trying to use that approach to handle your own requirements is not going to be clean or transparent.

Back to AOP. The author uses his own NAspect framework for run-time AOP however we were thinking of using PostSharp as compile time seemed good enough and it is more transparent. Having to use abstract factory, or just factories, for all object creation just does not appeal though.

The attribute based approach is cool though, and its similiar to the way you attach behavior with PostSharp . All in all I think I'm going to plow on with PostSharp and then see how it goes (as described in my post AOP and the Domain - Dirty Tracking).

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

Sunday, January 13, 2008

DDD with AOP and DI Presentation

A new DDD thread links to a talk about using AOP and DI to support DDD. The talk itself is very interesting, not sure I agree with all of it but it is good.

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

Wednesday, November 28, 2007

AOP - Alternatives To PostSharp

Whilst looking at PostSharp I found quite a few useful links and also managed to look at a few alternatives.

Aspect# seemed interesting but it only does virtual members (or interfaces I presume) and its certainly not transparent to the user of the classes as you have to go through an AspectEngine. Anyway no matter how useful it could have been it looks like Aspect# is a dead end and is on the way out.

Other than Aspect# there are a few other choices, Spring.NET has an AOP solution and Eric Bodden has a list of .NET AOP solutions and I'll definitely take a look at some of them, AspectDNG in particular sounds good.

I'll be interested to see if I can find any solution thats as simple as PostSharp Laos or that has such a nice way of supporting compile-time weaving.

Links - PostSharp

  1. Using AOP for validation
  2. PostSharp AOP reference
  3. AOP with PostSharp Part A
  4. AOP with PostSharp Part B
  5. Bitter Coder
  6. DotNetKicks - Not much yet...

Links - AOP

  1. Ayende - 7 Approaches To AOP In .NET
  2. Characterization Of Current Approaches
  3. Spring.NET
  4. Eric Boddens List Of Current Approaches
  5. Wikipedia

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

Tuesday, November 27, 2007

AOP and the Domain - Dirty Tracking

A new requirement has come in to our system, essentially we need to be able to tell external systems when (some) changes happen to our domain objects. How we notify the systems is one issue but how we actually track domain changes is another one.

Some of the changes are quite high level, such as a Customer state change, and some are just little changes to the data of an object, such as a change to a Customers first name.

We could handle the high level state changes by calling through Service classes, for example CustomerStateChangeService.Activate(customer). However we also need to think about how to track all the data changes, we've considered a few ways that we could do this and two of the most obvious are:

  1. Services - Instead of directly setting a Customers first name call through a Service which would then take care of ensuring that we give other systems a chance to track the change. We could look at something like the anticorruption layer example.
  2. Domain Events - The domain classes could raise events, to some extent this is nicely decoupled but it bothers us that our domain objects would be raising events simply because an external system needs to know about the change. It also means that pretty much every property setter in the domain could potentially be raising an event once its set the value, not very elegant.
  3. NHibernate - Maybe include an interceptor that can help us work out what has changed when NHibernate comes to persist. This sounds easy but in practice would be a mess and certainly isn't very intuitive.

Anyway these and other solutions didn't appeal so I started looking at PostSharp. Now I'm no fan of overly technical solutions to domain problems. However I'd heard good things about AOP and thought it might help us solve the problem, especially since logging is quite often given as an example of where AOP can help. I was thus hoping that it could give us a good, simple, solution to our problem.

However when I came to use PostSharp I couldn't believe how good it was. In particular it allows you to use attributes to specify code that you want PostSharp to inject in post-build...

Example

To show how simple it is I've tried to come up with what I consider to be a useful example which you can get from google code. In order to run it you first need to install PostSharp, once you've done this you can open and run the project.

First off note that SimpleDomainClass is marked with AllPropertySetsNotificationAttribute. If you open AllPropertySetsNotificationAttribute you can see that it is using reflection to attach an extra attribute, PropertySetNotificationAttribute, to each property setters.

This may seem silly until you run the application and see that the code in PropertySetNotificationAttribute.OnSuccess is being automagically run.

This is happening because the post-build PostSharp process is ensuring that where it sees a method boundary aspect, such as PropertySetNotificationAttribute, it inserts the necessary IL to ensure the code in the attribute is run.

You can see this if you open Reflector and view the disassembly output for SimpleDomainClass, look at the property setters and note the extra code including the call to OnSuccess in the attribute.

In case you were wondering this is a simplified version of the binding sample that actually comes with PostSharp.

Usage

In our case you could easily imagine PropertySetNotificationAttribute calling out to a IDomainChangeNotificationService, the actual implementation could be retrieved from a Service Locator or injected in using IOC.

Project References

You will note that our domain assembly references the assembly that I've put the attributes into and also PostSharp.Laos and PostSharp.Public. This bothers me slightly but from what I can see they are quite lightweight assemblies so it doesn't seem to be a killer.

Conclusion

I'm still at the earlier stages of understanding PostSharp but I'm very impressed.

Like TypeMock and NHibernate it is very powerful and also seems to come with very good documentation.

I'm also stunned by how easy it was to do what I wanted to in this case, but then I guess I shouldnt be as the docs indicate that Laos has been designed to be simple rather than being fully featured.

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone