Dynamic AOP Without Attributes

The AOP Engine now has XML mapping support, so you can put those attributes somewhere else...

<mappings>
 <type name="Activehead.AOP.Test.TestClass, Activehead.AOP.Test">
  <method name="Test">
   <dynamicAttribute type="Activehead.AOP.UseConstraintsAttribute, Activehead.AOP">
    <UseConstraintsAttribute/>
   </dynamicAttribute>
   <parameter name="i">
    <dynamicAttribute type="Activehead.AOP.GreaterThanAttribute, Activehead.AOP">
     <GreaterThanAttribute>
      <Value>100</Value>
     </GreaterThanAttribute>
    </dynamicAttribute>
   </parameter>
  </method>
 </type>
</
mappings>

.
.
.

public void SomeMethod()
{

System.Xml.XmlDocument doc = new System.Xml.XmlDocument();
doc.Load("mappings.xml");
AOPActivator.AddDynamicAttributes(doc.InnerXml);
TestClass myTestClass = (TestClass)AOPActivator.CreateInstance(typeof(TestClass));

// Do something

}

I've been wondering lately though if AOP is the right term for this project. In one sense, it is pretty similar to what some people have been calling AOP. But, it definately isn't JAspect. I agree with Anders that AOP (at least in the JAspect sense) is just not ready for mainstream yet. Too many concepts that are just too abstract right now ("pointcuts", "crosscuts", etc.). Additionally, without really intuitive IDE support, debugging could quickly become a nightmare to with heavy aspect usage.

In any case, this idea of declaritive service requests a la attribute based programming that a lot of people in the community are taking a stab at definately seems ready for prime time to me (especially when you don't have something like C++ macros to zap in a boat load of code for you without messing up your nice, clean source files).

The engine I have been working on is a bit different than the other approaches that I have seen. John Lam was working on a semi-runtime aspect weaver that used some MC++ interfaces to re-jit code on the fly (anyone know what ever happened to that?). Clemens is also using MC++ to hook into serviced components to apparently do something similiar to what Chris did with ContextBoundObjects in his MSDN AOP Article. As much as I love C++ and would enjoy digging into those gorey details, I really wanted to come up with a completely managed solution for a lot of reasons--one of course being that I eventually want to be able to run my code on non-MS platforms like Mono, if for no other reason than to say I can :-).

The engine itself is designed to allow both runtime and compile time support, so it does let you save "weaved" aspects to their own assemblies if you want, or just use the in memory copy. Of course, for ServicedComponents, this is another story, because you cannot instantiate a class in a dynamic assembly without first saving it to disk. So, that has to happen behind the scenes, if not directly.

Now that the validation attributes are all working, it is time to move on to some more useful things. I plan on building an entire security infrastructure on top of this to use in the BLLs of some apps... should be fun stuff :-).

1 Comment

  • Actually, CLAW did all weaving at run-time. So it is (was?) a dynamic aspect weaver. Because things were done at JIT compilation time, I would have minimal performance impact (just the overhead of calling the pre/post method via an x86 indirect call instruction). I also had the ability to re-JIT code as well, meaning that the aspects could be completely removed at runtime, so that there would be no perf impact whatsoever.





    Sadly, the M3 build of CLAW is in a state of limbo right now. I don't have the cycles to clean up the code so that others can work on it - heck I barely remember how to install the thing on another box. The M4 build actually had an installer, but it was never functional (this one had a fairly expressive weave definition language compiler).

Comments have been disabled for this content.