Introduction

The LinFu Framework is a collection of a few things that I've always wanted to do in .NET, but unfortunately, there weren't any existing implementations that matched all of my needs. So, like any other curious programmer, I set out to write my own library and this is the result. I can ramble on and on about it, but this picture should give you a general idea of what LinFu does and where this series of articles is going:

Note: The word LinFu (Pronunciation: LINN-FOO)is actually an acronym that means "Language INdependent Features Underneath [.NET]." What started as simple tinkering into dynamic proxies and Reflection.Emit four years ago slowly evolved into a personal project in extending existing .NET languages without changing their respective syntaxes. This entire framework is a culmination of those years of my own personal research and, after some deliberation, I've decided to license this whole project under the terms of the LGPL license. This means that everyone will be free to use the library without royalties as long as it adheres to the terms of that license. If you are going to use this in your own commercial projects, then I would absolutely love to get some constructive commercial feedback (and a few professional references wouldn't hurt either).

If there are any features that you think should be added (or any features you want to add yourself), just send me a copy of it so that I can look at it and merge it into the codebase that I currently have with me. Anyway, let's go back to the article…

Language Independent?

LinFu, in its most basic form, is nothing but a managed DLL library that is compiled into IL. Since anything written in IL can be used by any .NET language, all the features of LinFu that I will be showing in the following articles can be consumed by any .NET language. Using this rationale, LinFu extends languages like VB.NET and C# without affecting their respective syntaxes. It supports the following features:

Dynamic Proxies

LinFu has its own proxy generator, which even predates other more prominent implementations such as CastleProject's Dynamic Proxy and Castle DynamicProxy2. This version of LinFu DynamicProxy has supported generics ever since the VS2005 release and, based on my current benchmarks (which will be discussed in this article), it consistently outperforms Castle's implementation by a factor of at least 200%. In short, LinFu's Dynamic Proxy is lean, mean and very, very fast.

Duck Typing and Late Binding

Dynamic languages such as Ruby and Python (and to some extent, VB.NET) have the amazing ability to call methods at runtime without knowing exactly which methods they will be using at compile time. Furthermore, those take that concept even further and actually "infer" which method should be called based on the arguments that are passed to the method at runtime (aka "Duck Typing"). It would be nice if there were a way to do that natively in C# (2.0), but unfortunately, that's not entirely possible... unless you use LinFu, of course! LinFu does some mind-bending tricks with the C# syntax to make it work and, later in the series, I'll show you how it all works behind the scenes.

Ruby-style Mixins

Dynamic languages have the ability to seamlessly and dynamically modify their classes at runtime so that each class can practically add and subtract methods (and even add other classes and interface implementations) to and from each class implementation. Believe it or not, I've found a way to implement the same type of dynamic mixins in both C# and VB.NET and still be able to adhere to the strongly-typed rules of each of both languages! (Well, maybe not VB.NET, since sometimes it can be loosely typed, but I digress). With LinFu, you can incrementally build an object's implementation at runtime just as easily as one can incrementally build an SQL string. Want to dynamically implement an interface at runtime, but don't have a class that implements it at compile time? No problem. LinFu can incrementally stitch methods together to form one cohesive interface implementation, all at runtime.

Delegates with Lambda Arguments (aka, "Currying")

While languages such as C# 3.0 and the upcoming version of VB.NET have support for defining Lambda "Expressions," one feature that I've always wanted to have is the ability to take any delegate and actually hard-bind (or close) one or more of the delegate parameters to a specific arbitrary value. In other words, this feature allows you to "simulate" delegate calls by hard-wiring some (or all) of the arguments passed to a delegate when an event is fired. In other words, LinFu makes it very easy to mock events.

Universal Event Handling

One of the biggest problems in writing an application that uses the MVC pattern (or the MVP pattern) is finding a uniform way to have the controller handle events that are fired from the Presentation/View without knowing "a priori" the signature of those events at compile time. LinFu can actually attach itself to any event fired on any object at runtime, regardless of the delegate signature that event might be using.

A Very, Very Simple IoC Container

Imagine that you had an Inversion of Control (or Dependency Injection) container that didn't rely on an external configuration file (such as an XML file) to assemble itself. Furthermore, suppose that the only "configuration" that you would have to do would involve less than a few lines of code and a simple XCOPY operation in order to get everything up and running. Does it sound too simple? Well, seeing is believing and in Part IV, I'll do my best to make you a believer.

Design by Contract

There have been quite a few attempts at creating a DbC Framework in .NET (and even in Java, with JContract) such as eXtensible C#, Kevin McFarlane's DbC Framework and the like, but few of them have been able to effectively emulate the Eiffel language's DbC mechanism without tying their respective implementations to their particular language (in the case of XC#) or cluttering their domain methods with numerous precondition, postcondition and invariant checks (as is the case with McFarlane's library). LinFu allows you to transparently inject preconditions, postconditions and invariants into your code at runtime, regardless of whether or not you actually have access to the source code of the library you wish to inject. Want to wrap System.Data.IDbConnection in a user-defined contract? No problem, it only takes a single line of code. Want to dynamically generate verifiable contracts at runtime? LinFu can do that, too. When used in combination with the Simple.IoC container, it can even inject contracts into your apps while it's still running, all without recompiling your entire application.

As you can see, LinFu can do quite a few interesting things. In publishing these articles, I hope that I can help a sizeable number of developers out there to write better code through the use of my library. For me, it's always a pleasure to give back to the developer community as a whole and any additional hour that I can spend saving any other developer from having to write more boilerplate code is time well spent. So, without further ado, let's get started!

Background

This article assumes that you're familiar with the concept of dynamic proxies and, for those of you who are interested in figuring out how it all works, I'll do my best to explain it in the next few sections without having to dive into the gory details of Reflection.Emit. If you're a casual developer, however, you can just browse the next few sections to use the code.

DynamicProxy

This article will show you how to use LinFu's DynamicProxy to add "hooks" to your method code so that you can arbitrarily inject new code into your application at runtime. This can be useful if you want to add additional features to your application (such as logging or performance timing), but you don't want to have those additional features to be cluttered across your codebase.

Using the Code

LinFu's DynamicProxy library allows you to intercept any method call made to any virtual method in your object instances and replace those methods with your own implementation at runtime. For example:

Wrapping the Greeter Object

Depending on what your needs might be, you'll have to implement one of these two interfaces to create your own interceptor. In this case, we're going to implement IInvokeWrapper so that we can add some additional behavior to the Greeter class before and after its Greet() method is called:

The first thing that you might notice here is that the interceptor needs to have a reference to an actual instance of a greeter object. That's because LinFu's dynamic proxies don't actually have a behavior (or an intrinsic state) of their own. Every proxy generated by LinFu dynamically overrides all of its parent's virtual methods. Each one of its respective overridden method implementations delegates each method call to the attached IInterceptor object. In many respects, each proxy is like an empty shell. Without an attached interceptor, a proxy simply throws a NotImplementedException.

A Manually Written Proxy

If I were to write the proxy by hand, it would look something like this:

As you can see here, LinFu's dynamic proxies only redirect calls to an interceptor, despite whatever implementations each proxy might inherit from its original base class. When a proxy is called in place of an actual object, it constructs an InvocationInfo object with all the necessary reflection details. This is so that the interceptor can either call the original implementation of that method or replace it with its own brand new implementation.

Most of the properties in this class are fairly self-explanatory. The Target property refers to the proxy instance that intercepted the method call, while the StackTrace property refers to the state of the call stack when the proxy was called.

What seems to be missing here, however, is any reference to the actual object that will provide the implementation for this proxy (in this case, a Greeter object). This is done by design. As far as the LinFu library is concerned, a proxy's sole task is to delegate its implementation to an IInterceptorobject which may (or may not) have an implementation of the real object as its implementation (i.e. the actual Greeter object). Everything else (from the proxy's standpoint) is irrelevant.

Note: I separated the proxy instance from the proxy implementation (and thus, the real object) to make it easier to manage multiple proxies at once. In theory, a handful of these proxies could be pooled together and reused to save memory, but such a task is way beyond the scope of this article. I'll leave it to the readers to come up with a scheme to make that work.

Putting It All Together

Now that there is a GreetInterceptor class, the only things left to do are to instantiate the proxy and attach it to the greeter:

Once the greeter proxy object is instantiated and initialized with the interceptor, the only thing left to do is to run it:

// Since the interceptor is in place, the original "Hello, World!" message
// will be replaced with "Hello, CodeProject!"
greeter.Greet();

After the Greet() method is called, the proxy will redirect the call back to the GreetInterceptor instance, which will provide the replacement implementation for the Greet() method. Aside from the proxy instantiation itself, this process makes intercepting method calls relatively transparent. What if, however, you need to replace the interceptor?

The IProxy Interface

As it turns out, every proxy generated by LinFu implements the IProxy interface. Since the IProxy interface has an Interceptor property, replacing an existing interceptor is as easy as doing the following:

Points of Interest

One thing about LinFu's DynamicProxy that's always fascinated me is its raw speed. On my 1.8GHz Dual-core laptop, it takes only a few milliseconds to generate a single proxy. For the sake of reference, I've done a simple benchmark on LinFu's Dynamic Proxy versus CastleProject's DP2.

Benchmark Setup

This benchmark was run against both LinFu and Castle DP2 libraries with proxy type caching turned off. This was to prevent any of the results from being skewed due to cache hits from either library. For Castle's DynamicProxy2, I had to modify BaseProxyGenerator.cs, line 160, to disable caching:

For LinFu, I disabled the proxy cache from being used by setting its reference to null in Program.cs, line 104, in the benchmarking code:

…
ProxyFactory factory = new ProxyFactory();
// Disable the cache in order to prevent
// the factory from skewing the benchmark results
factory.Cache = null;
…

Benchmark Results

This test simulates a worst-case scenario where each proxy generator (or factory) effectively has to generate up to one thousand unique proxy types in succession. As the results of this benchmark show, both of these libraries scale quite well when generating up to one hundred unique proxy types. However, Castle's performance significantly slows down once the benchmark passes the one hundred type threshold. In fact, as it approaches the point where it has to generate a thousand unique types, it runs five times slower than LinFu's implementation. Other than that, I think the benchmark speaks for itself.

Since type caching is enabled by default in both libraries, however, multiple calls to generate the same proxy type will be cached and those calls (in practice) will only incur a minimal amount of overhead. Nonetheless, this benchmark shows the speed differences between the two libraries and, as these numbers show, LinFu's DynamicProxy is much faster than its Castle counterpart.

Note: If you should be inclined to perform benchmarks of your own, I've included the benchmarking code as part of the source code, as well as the Excel 2007 spreadsheet that I used to generate that chart for the benchmarks. I've also included a copy of the modified Castle.DynamicProxy2.dll with its caching disabled, just in case someone else on CodeProject would be interested in adding even more benchmarks.

Limitations

There are a few things that LinFu's Dynamic Proxy generator cannot do. These are:

It cannot inherit from sealed types.

By itself, LFDP cannot override a sealed type. However, once I get to discussing LinFu.Reflection, I'll show you how to get around this limitation.

It cannot override non-virtual members.

This one is pretty self-explanatory. Lately, I've been playing around with using the Mono.Cecil library to make non-virtual methods virtual, but so far, I haven't come up with anything robust enough to include in LinFu. I'll update this article once I come up with something reliable.

Special Thanks

Thanks to Jeff Brown and Julien Dagorn, LinFu.DynamicProxy now supports overriding methods with ref and out parameters. Thanks for the input, guys!

License

The entire LinFu Framework is licensed under the terms of the LGPL license, meaning that you are free to use the library DLL in your commercial applications without royalties, but if you make any modifications to its source code, then you must publish the source code so that everyone else can use it.

Coming Up in the Next Article

LinFu's DynamicProxy is only a rudimentary part of what the overall LinFu Framework has to offer. In the next article, I'll show you how you can use the features of C# 3.0 along with LinFu to dynamically generate interface implementations at runtime. I'll give you an example. Suppose that in my domain model, I have the following interface definitions defined:

For now, I'll let you digest that last block of code in your mind for awhile. Suffice to say, LinFu allows developers to use dynamic language features from within the comforts of their own statically typed languages. Meanwhile, I'll be off writing the next article. Stay tuned!

and this is the output:Before
In the act
10 abc
11 bc
12 c
13
After
-> 0

And the problem is:
I was expecting greet.Counter to return 13, but the only way to get 13 is to use actualGreet.Counter. It seems that DoInvoke is using actualGreet and not greet as one might expect.
Calling a method of greet and using actualGreet for properties makes the code cumbersome. Is there something you can do about it Philip?

Calling a method of greet and using actualGreet for properties makes the code cumbersome. Is there something you can do about it Philip?

Actually, there's nothing I can do about that, given that LinFu.DynamicProxy can only intercept virtual methods and properties, and since the Counter property is marked as non-virtual, then there's not much I can do about it. However, if you change your Greeter code from:

I'm facing a problem where a proxy would be a very good solution. Let me explain it.

I have a bunch of classes that are used as business objects. Each of them have some properties that can be written (get;set;) and a IsDirty flag. I wanted to be able to wrap any of these classes in a proxy. That proxy would override only the properties set methods to set the IsDirty to true. I was able to select only a part of the properties by using custom attributes.

I think it would be a good idea to create a custom attribute like ProxyOverridable (or ProxyNotOverridable). The created proxy would override only the selected subset of methods. I know this would bind the class declaration with the proxy creation, but it could make the created proxies run much faster.

I think it would be a good idea to create a custom attribute like ProxyOverridable (or ProxyNotOverridable). The created proxy would override only the selected subset of methods. I know this would bind the class declaration with the proxy creation, but it could make the created proxies run much faster.

It's an interesting idea, but the reason why I kept the proxy and the class instance separate is simplicity, and putting the two together would make the code more complex than it has to be.

There is, however, a way to do this without having to rearchitect LinFu.DynamicProxy. Here's a quick way to do it in less than 100 lines of code:

Using that example above, I created an interceptor that watches setters as they get called and keeps track of which properties get changed. Whats interesting about this one is that I'm actually implementing IDirtyTracker through the interceptor itself, and by redirecting the actual implementation of IDirtyTracker, I can keep my domain model free of any change tracking code. Anyway, I hope it helps! Enjoy!

OK - I've now started using this in anger and I have to say it's damn fine. I've taken your dirty tracker here and modified it slightly (I'll post the change in the morning), but it really really works neatly. The only problem I had was that it took me a while to realise that I had to make my properties virtual for this to work. Anyway, just thought I'd let you know that it is working out "in the real world".

OK - I've now started using this in anger and I have to say it's damn fine. I've taken your dirty tracker here and modified it slightly (I'll post the change in the morning), but it really really works neatly. The only problem I had was that it took me a while to realise that I had to make my properties virtual for this to work. Anyway, just thought I'd let you know that it is working out "in the real world".

Thanks Pete. All this talk of dirty trackers is starting to make me wonder how difficult it would be to write an ORM with all this stuff--and I have to say, it's pretty tempting to do so! I have already written a generic LINQ Expression Tree parsing library that allows you to parse an expression tree just by using LINQ to object queries, and with all these other pieces coming together, an ORM might just be a viable option. Anyway, it's good to see that some of my projects are starting to bear fruit in the real world. Thanks again for the feedback

Philip this is the code that I am using to track the status of the properties. The key differences between the code you posted and this implementation is the use of generics, the fact that the proxy is returned from the class and the use of my EventPool class (see my article on the EventPool here[^]* shameless plug *;)).

All this talk of dirty trackers is starting to make me wonder how difficult it would be to write an ORM with all this stuff--and I have to say, it's pretty tempting to do so!

Let me know if you'd like a hand with that. It sounds interesting. Oh, I'm also looking at using your stuff to dynamically inject validation into classes. I wrote a validation framework a while back that could be attached to properties and it made use of things like validation attributes, but I was never quite happy with it. Your articles are the missing piece in the validation, so I'm going to go back and dust them off.

Pete, it's a good thing that you mentioned your event pool--there's something interesting that I just recently discovered about LinFu.DynamicObject--it can also mock event sources! For example, let's say I have the following interface defined with a single event on it:

The add_SomeEvent is actually called when you wire up an event handler to an object instance of ISomeEventSource:

ISomeEventSource source = dynamic.CreateDuck<ISomeEventSource>();
// The call is actually being routed back to the DynamicObject
source.SomeEvent += source_SomeEvent;

Now, I've been looking at your EventPool, and the first thing that comes to my mind is that with this feature, you can effectively isolate your client code to the point where they don't even know about the existence of the event pool at all--all they have to do is attach their handlers to an interface instance that actually routes its calls back to the pool. From the client's perspective, the EventPool is practically invisible. (Behind the scenes, however, the event pool will connect the actual event sources to the event handlers).

There's quite a lot of interesting ways to apply this technique. Another way one could use this is to abstract away the process of creating the event source using LinFu's IOC container. Event subscribers could request for an instance of a particular interface (with events defined on it), and you can modify the container's behavior to pass out interface instances which connect all event handlers back to the event pool. What do you think?

As for your validation framework, I think a sound approach would be to do something like Rocky Lhotka did with CSLA.NET. What he did was keep a list of "broken rules" that are added to the object every time the object reaches an invalid state with one (or more) of its properties. It might seem complicated, but it actually follows the same principle as the dirty tracker. All you would need to do is to run a list of rules to check against an object every time a setter is called. For every rule violated, all you have to do is add a broken rule to the object--you can think of it as a "BrokenRule" tracker.

LinFu's DBC is actually a variation of this style of validation; the only difference is that if an precondition/postcondition/invariant is violated on an object instance, the contract verifier causes the program to fail, and fail hard. If you need an approach that is a bit more lenient, then you might want to try the one I described above. I hope that helps

Now, I've been looking at your EventPool, and the first thing that comes to my mind is that with this feature, you can effectively isolate your client code to the point where they don't even know about the existence of the event pool at all--all they have to do is attach their handlers to an interface instance that actually routes its calls back to the pool. From the client's perspective, the EventPool is practically invisible. (Behind the scenes, however, the event pool will connect the actual event sources to the event handlers).

Interesting idea. It's one area that I'll definitely be looking at.

Philip Laureano wrote:

sound approach would be to do something like Rocky Lhotka did with CSLA.NET

That's what I did with the original version. The problem with it was that each property had to raise an OnChanged event to signal the validation to do this. What I envisaged was taking your code and using it as the base for abstracting this out - in just the same way that the Dirty Tracker does.

Now, I do like DbC and am looking forward to seeing your implementation, but the stuff that I was doing with validation allowed for trigger effects to take other conditions into account and to act as setters as well. So, if you change property A then property B and property C might be invalidated. In this respect, what I did was close to CSLA.NET but went a bit beyond by allowing rule A to update value B and then allow value C to be checked dependent on this update. The proxy injection stuff you've done here opens this up so much for me by allowing me to dynamically implement different rules.

Now, I do like DbC and am looking forward to seeing your implementation, but the stuff that I was doing with validation allowed for trigger effects to take other conditions into account and to act as setters as well. So, if you change property A then property B and property C might be invalidated. In this respect, what I did was close to CSLA.NET but went a bit beyond by allowing rule A to update value B and then allow value C to be checked dependent on this update. The proxy injection stuff you've done here opens this up so much for me by allowing me to dynamically implement different rules.

It sounds interesting. With your approach, I think it might be possible to add validations that span across multiple object relationships. I'm not so sure about allowing rules to change the object state, however. It sounds like you might be doing two things at once here--first, you're checking to see if the object adheres to a given rule, and second, you're running another rule dependent on the current state of the object. If coupled together, those two operations might be more complicated than they need to be.

Based on your description, it seems like you might be able to simplify things by giving your rules the ability to specify whether or not they apply in a given situation (and thus, determine whether or not they should run), and secondly, you could abstract away the operation to perform once the rule is run.

The only issue that I see with this is that their is actually two types of rules in this scheme: validation rules (which state whether or not an object is valid), and business rules (rules which modify the object's state in response to a certain condition). Either way, the proxy injection approach should make applying both of these rules pretty easy for you, assuming that you haven't already figured this out on your own.

Now that I think about it, the more we talk about this, the more it sounds like the parts for a proto-ORM are coming together. So far, in addition to whatever validation framework you might write, I have the following at my disposal:

-A dirty tracker
-A LINQ Expression Tree Parser framework
-LinFu.DynamicObject for field to property mapping using getters/setters
-An IOC container to abstract the data source from the client
-A DbC framework to make sure that it all works properly
-A universal event handler to wire all the events together

For me, it just seems wierd since I never really planned to form these pieces from the start--I just discovered them. The emergent pattern looks similar to an ORM, and depending on how all this pans out, I just might go ahead and do it...

With your approach, I think it might be possible to add validations that span across multiple object relationships

That was the whole idea originally. To be honest, this idea was based on work that I did in Oracle and Informix back in the early 90s. There we had an entire metabase to work with. Again, the setter methods were used to respond to rules, so we had rules that were abstracted to the level of get, set and check which did just that. The get rules retrieved the relevant information, the set rules set values based on certain conditions and the check rules were responsible for ensuring that values are appropriate.

You're right that there are type discrete types of rules here, and I was thinking of using the Proxy Injection to handle these. Things that I'm considering include having proxys to run the rules, and proxys to monitor rule re-entrancy. In other words, there needs to be a mechanism to ensure that you don't go into an endless loop based on rule handling. Hmmmm. Seems that there might be a basis for a design coming out here.;)

I think the problem is that I used the term validation. There is more to it than that - it's a way of abstracting the business rules from the actual data. Somthing that fits in with your model very neatly. I spent a while working in the Insurance industry and business rules engines were commonplace there, so you had systems that responded to application forms to work out customers actuarial risk for instance.

Tell you what, once I've got the basics of the proxy based rules knocked together, I'll forward a copy onto you to see what you think. I must admit though, that being able to tie this into LINQ is pretty exciting. Damn, I haven't felt this jazzed about a software project in quite a while.