A Cowboy, a decorator and an interceptor does some logging
Imagine that we have a service that’s responsible for fetching some pagedata. The following interface and class is used
Now, for some reason your code seems slow and you have a feeling that it might be your PageLoadService that’s the cause. Since it’s always a wise idea to actually measure this instead of guestimate where performance bottlenecks are you decide to add a simple stop watch to track the time the method takes.
(Nitpick corner. No, I don’t suggest using Response.Write “logging”. This was just quick to do to get the point about the various ways to do the logging across.)
One, the cowboy way
Now, if you’ve read any of my other posts on design and testing you can probably tell that this code won’t make the S in Solid very happy since it’s now responsible for both fetching page data and some sort of logging. It can also be cumbersome to maintain since you have to edit this code if you want to activate / deactivate the logging.
Two, using a decorator
We revert the PageLoadService back to it’s original state since it won’t handle the logging anymore. That will be handled by a decorator that simply adds the logging and then calls the original service to perform the actual fetching of the page data.
We start with an abstract base decorator
and then create a concrete implementation for our stop watch logging.
We simply new up the decorator scenario we’d like. In our case we only have one so the initiation looks like this
Three, using an interceptor
In my previous post about why you have to mark you properties as virtual when using PTB I talked a bit about interceptors and dynamic proxies. What we basically want here is to run some code before and after the actual call to the page data loading service. As such, using a interceptor would solve this problem quite nicely.
We start with a class that build the proxy for us.
The generic Create method simply takes a target (which is the class to intercept) and the class with which to intercept it with.
The class that does the interception has to implement the IInterceptor interface.
This method is called when a suitable method to intercept (in our case it’s every method) is called. We can then do whatever we please before telling the method to go ahead and execute. This is done on line 8 with the call to the Proceed method.
To use this we simply call the static Create method on our InterceptorBuilder.
Note that our interceptor can basically intercept any class that implements an interface so if we wanted to implement logging on another class it would be as simple as changing the initializing.
This would perform the stopwatch logic for both Do1 and Do2.
This is of course not always what you want and not something I’d generally recommend. Often you’d want to specify which members of your class that you’d want to be intercepted. There’s a lot more to be said about the DynamicProxy framework but hopefully this short post at least somewhat inspired you.