AOP with the created presenters/controllers

Apr 8, 2008 at 7:06 AM
Hi,

Currently I am looking at the possibility of AOP together with the presenters/controllers. This thought came about as there is a need for me to have an audit log of certain functions when they are invoked by the user. Use of AOP will allow me to express which functions I need audited in a seperate module rather than putting in audit/logging codes all over my functions.

The Policy Injection Application Block would seem to be what I am looking for. Integrating it, however, seem to be quite tedious, as it looks like I have to rewrite the presenter/controller creation code with the PIAB (havent a clue where it is at the moment) and recompile the WCSF blocks. I would like some advice here, if there is a simpler way of doing AOP. Or if not, some guidance on which part of the block to integrate the PIAB. Or maybe i should just dump the audit codes into the functions where I need them heh.

Thanks and regards.
Apr 16, 2008 at 5:49 PM
Hi Joseph!

You don’t need to rewrite the presenter/controller creation, instead, you can use the Wrap method of the PolicyInjection class with existing objects. For example, you may wrap the presenter after it’s created in the View:
[CreateNew]
public DefaultViewPresenter Presenter
{
    get
      {
            return this._presenter;
      }
    set
    {
        if(value == null)
            throw new ArgumentNullException("value");
        
        this._presenter = value;
        this._presenter.View = this;
 
        PolicyInjection.Wrap<DefaultViewPresenter>(this._presenter);
    }
}

  • Note: the classes you want to wrap have to derive from MarshalByRefObject to be interceptable by PIAB.

A quote from the PIAB documentation:


Creating an Instance of an Interceptable Target Class

You can use the Policy Injection Application Block factory methods to create an instance of any class that is interceptable or wrap an existing instance of any class that is interceptable. The term "interceptable" describes classes that can be policy-enabled using the built-in interception mechanism. Interceptable objects are those that do one of the following:
  • Derive from the class MarshalByRefObject. The Policy Injection Application Block can intercept and add handlers to public methods and properties of classes that inherit from the abstract base class MarshalByRefObject. The .NET Framework uses this class for objects that exchange messages across domain boundaries using remoting.
  • Implement an interface. The Policy Injection Application Block can intercept and add handlers to public methods and properties defined in the interface that classes implement.
The Policy Injection Application Block factory class provides two methods for creating or obtaining object instances:
  • Create. This method creates a new instance of a policy-enabled interceptable target object.
  • Wrap. This method adds policies to existing interceptable target object instances.


Please let me know if this helps.

Jonathan Cisneros
http://staff.southworks.net/blogs/jcisneros/default.aspx
Apr 20, 2008 at 4:12 PM
Hi Jonathan,

Thanks for the help! Certainly looks good.

The presenter cannot inherit from MarshalByRefObj as it already inherits from a base presenter class, and making the PolicyInjector wrap around a presenter that implements an interface seem to have certain constraints as well.. If i wrap and declare the presenter in the view as an IPresenter object, i will not be able to use the methods from the base presenter class.

Probably need some changes to the recipe or the block (let base presenter class inherit MarshalByRefObj) but seems quite easily doable now!
Jun 13, 2008 at 9:56 AM
The above suggestion never works. has anyone ever succeed in wrapping AOP around view or presenter ? ... please share .. thanks

Elvin
Jun 13, 2008 at 1:47 PM
My mistake, it works if implement interface IPresenter to the Presenter class: 
PolicyInjection.Wrap<IPresenter>(this._presenter); 

Now, I am testing if I can intercept the method OnViewLoad() only, and apply a custom handler to it to do URL validation.

Feel a bit uncomfortable, the rule of PIAB that it must be wrap by MarshalByRefObj or interface to do AOP like work is creating a lot of problems (such as in this ViewPresenter pattern) and limitations. I just came across PostSharpEntLib4, it seems a better alternative to PIAB, much easier to use and truely AOP. The only worry is that it is too young and if stable enough at current stage. Will explore and try out both now ..

Elvin
Jul 3, 2008 at 2:16 AM
Hi,

My requirement to do logging of functions went away so I did not look too much into this anymore....

I was experimenting with PostSharp Laos for use with WCSF (not PostSharp4EntLib), weaving aspects into the presenter module.  Seems to be working fine on the few simple websites I did up with WCSF, and the strange thing is, the performance of the websites (in terms of timing when retrieving pages from the server) improved rather than worsen, as I expected it to be.
Jul 5, 2008 at 3:13 PM
Joseph,

Sounds very interesting!
 
Just out of interest, what are you using PostSharp for in your WCSF solutions? And when you say response times improved, what was this in comparison with?

Simon
http://blogs.msdn.com/simonince
Oct 7, 2008 at 6:24 AM
Hello,

Late reply here... Was attempting to use PostSharp as a means of auditing what users do.
When users click a button to perform certain operation, this button will call the appropriate methods on the presenter.  The methods are weaved with PostSharp Laos methods that log down this user activity.

Reponse times is in comparison with the non-weaved presenter dlls.  Which is strange since I would expect that a method that is weaved with aspects perform slower than the original one..
Oct 7, 2008 at 10:27 AM
As for performance of code enhanced by PostSharp... it really depends to what you are comparing.$0$0$0$0If you apply an aspect to a method doing pure arithmetic or pure memory access, it will be much slower. Especially if this method is invoked often. But it generally does not matter on methods invoked rarely (like a click handler) and anyway with a big overhead.$0$0$0$0$0Look at the generated code using Reflector and you'll see.$0$0$0$0$0-gael$0