Dynamic Proxy
There are 24 entries for the tag
Dynamic Proxy
There seems to be much confusion around two kinds of proxies that Castle Dynamic Proxy provides - InterfaceProxyWithTarget and InterfaceProxyWithTargetInterface. On the surface they both appear to be doing the same thing. Rule of thumb: If you’re not sure which one you want – you want the one with the longer, confusing name – InterfaceProxyWithTargetInterface. InterfaceProxyWithTargetInterface seems to be used less often, which is a shame, because what people really want 99% of the time is actually InterfaceProxyWithTargetInterface. However I suppose due to it’s extremely confusing name, and no clear apparent...
We’ve covered almost all of Dynamic Proxy. If you followed along through this series, you now know 95% of Dynamic Proxy 2.1 features that get used 99,9% of the time. Now is the time to wrap up, and with that we’ll review some of the most common pitfalls that you may encounter when developing code on top of Dynamic Proxy. Leaking this Consider this simple interface/class pair public interface IFoo
{
IFoo Bar();
}
public class Foo : IFoo
{
...
As of now Dynamic Proxy is passing all the tests under Silverlight. There’s still some work to do, but it is pretty stable the way it is, and it’s been used by Silverlight versions of Rhino Mocks, Moq and probably some others as well for some time. Technorati Tags: Castle,Silverlight,Dynamic Proxy
Wow, what I had planned as few parts tutorial has turned to nothing less than full examination of Dynamic Proxy capabilities. Of all most important features we' have basically just one left – proxy persistence, which is what we’re going to talk about today.
Discussion
Although Dynamic Proxy’s name suggests that it’s useful for… well creating proxies on the fly at runtime, there are other scenarios where the framework can be useful. We’ve seen one such scenario last time, when we created mixins, not using proxying at all.
Also the dynamic aspect of proxies is not always what we want. This is not...
So far we covered most of basic features of Dynamic Proxy, except for one – mixins. Not getting into theoretical details, mixin is an object that stitches many other objects together, exhibiting behaviors of all these objects. Let me illustrate that in pseudo code: var dog = Dog.New();
var cat = Cat.New();
var mixin = mixin(cat, dog);
mixin.Bark();
mixin.Meow();
In most languages this is achieved through multiple inheritance, but this is not allowed in the CLR, which imposes certain limitations on how mixins are implemented and work in Dynamic Proxy. We can’t have...
One more thing I mentioned in the 11th part of the Dynamic Proxy tutorial, was that I think behavior of class proxy when the class implements the additional interfaces was a result of an omission, and that it’s a bug. The issue was raised by Kenneth Xu actually roughly by the same time,on the Rhino Mocks discussion group. Anyway, this is now fixed in the trunk, and will be in version 2.2. There’s just one thing to be aware of – you will get the old behavior (no target) for members that are implemented explicitly. This is the...
In the 11th part of the Castle Dynamic Proxy tutorial, I mentioned that surprising behavior of additional interfaces in case of interface proxy with target is not considered a bug. Coincidently, just few days later a user started a thread on our discussion group regarding this issue. After some discussion we decided to change that, so starting with version 2.2 (or now, if you’re using daily builds) this behavior is no longer true. We aligned it with how interface proxy with target works. Actually, this (not real) part of code illustrates the new behavior. Let’s assume we’re calling...
If you’ve been following the tutorial, you should remember that Castle Dynamic Proxy provides proxying capabilities by generating types at runtime. Dynamic code generation is not a lightweight operation, so pretty important aspect of Dynamic Proxy is its caching mechanism which we’ll going to cover in this post.
Let’s consider the following piece of a test:
var proxy1 = generator.CreateClassProxy<Foo>(new FooInterceptor());
var proxy2 = generator.CreateClassProxy<Foo>(new BarInterceptor(), new FooInterceptor());
Assert.AreEqual(proxy1.GetType(), proxy2.GetType());
Will it succeed? The answer is – yes. In this simple case both proxies would be semantically identical, so generator (or more precisely IProxyBuilder that the generator is using) caches the type that...
So far in the tutorial we’ve covered most of the basics. However, we were always proxying just one type, be it a class or an interface. There is quite often a need to do more. What if a class implements more than one interface, and we want them all proxied? What if we want the proxy to implement interfaces the target type does not implement. Today we’ll talk about how to do just that, so let’s get straight to it. If you look into the API you may notice that for every kind of proxy there are overloads that...
I’ve been doing a lot of work with WCF lately. It’s a great framework, and I really like it, but it has its drawbacks. First of all, it is overly complicated in certain places (security!), which makes it really hard to use sometimes. Its sheer size, makes it also hard to grasp. It has a lot of extensions points but the fact that you have to plug into them yourself adds to that complexity. It simply begs for good IoC integration.
You can partially alleviate that by using Castle WCF facility that lets you use IoC container to extend WCF, but...
After a longish break we’re back to the Castle Dynamic Proxy tutorial.
The three kinds of proxies we talked about so far (class proxy, interface proxy with and without target) are the only kinds of proxies most users will ever use. There is however one more kind – interface proxies with target interface.
When I say most users will never use it, by most I mean roughly 99%. I, personally haven’t used it. Whole Castle project stack uses it in only one place that I know of – WCF facility. This proxy kind is used in really rare cases, and you can...
This is part IX of my ongoing tutorial on Castle Dynamic Proxy. If you are new to it, you probably want to read previous parts first: Introduction The what, why and how Selecting which methods to intercept Breaking hard dependencies InterceptorSelector, fine grained control over proxying ...
After my post comparing different dynamic proxy frameworks, many people were surprised by the poor performance of LinFu.DynamicProxy framework. In the update I noted that it was gathering the stack trace for each intercepted call, that made the framework so slow. Philip, the author of LinFu updated the framework, removing usage of StackTrace. It made a drastic change in the performance, and my previous comparison no longer correspond to current characteristics of the framework. As such I decided to re-run the test. Here are the results: All the times are roughly 10% better than...
This is part VIII of my ongoing tutorial on Castle Dynamic Proxy. If you are new to it, you probably want to read previous parts first: Introduction The what, why and how Selecting which methods to intercept Breaking hard dependencies InterceptorSelector, fine grained control over proxying ...
A recent comment on Twitter from Tim Barcz started me thinking about alternative proxy frameworks (alternative to Castle Dynamic Proxy that is). Recently LinFu Dynamic Proxy started gaining some popularity, after it was included as one of standard bytecode providers in NHibernate. Disclaimer: To make things clear. I'm a long time user of Castle Dynamic proxy and I may be biased towards it. I also happen to know how to use it, contrary to all the other frameworks, that’s why the following test may not be realizing their full potential. If you spot...
This is part VII of my ongoing tutorial on Castle Dynamic Proxy. If you are new to it, you probably want to read previous parts first:
Introduction
The what, why and how
Selecting which methods to intercept
Breaking hard dependencies
InterceptorSelector, fine grained control over proxying
...
This is part VI of my ongoing tutorial on Castle Dynamic Proxy. If you are new to it, you probably want to read previous parts first:
Introduction
The what, why and how
Selecting which methods to intercept
Breaking hard dependencies
InterceptorSelector, fine grained control over...
This is part V of my ongoing tutorial on Castle Dynamic Proxy. If you are new to it, you probably want to read previous parts first:
Introduction
The what, why and how
Selecting which methods to intercept
Breaking hard dependencies
Our Freezable library is starting to work quite well. However, there are still few glitches we need...
In the last part of the tutorial we created a method GetInterceptedMethodsCountFor that I promised I’ll talk about soon. While we’re at it, we’re going to fix another design flaw of our Freezable class.
To do its work, it holds a hard reference to each and every freezable object it creates. This is obviously not a big deal if you create only a handful of freezable objects that are we want to be alive for the entire time the application is running.
private static readonly IDictionary<object, IFreezable> _freezables = new Dictionary<object, IFreezable>();
However, in most cases the objects we create are transient,...
Welcome to the 3rd part of my Dynamic Proxy tutorial.
If you’re new here, you may take a look at previous parts first
Castle DynamicProxy tutorial part I: Introduction
Castle Dynamic Proxy tutorial part II: The what, why and how
We’ll start by updating our CallLoggingInterceptor class, so that we can use it in tests. What we need from it, is to enhance its functionality, so that it not only logs (to the Console) the calls, but also keeps a count of calls. To do that we add a property called Count, which gets incremented each...
After my first attempt at making IInterceptorSelector support in DynamicProxy actually work, there has been a discussion on castle-dev discussion group, about the implementation, its implication and features. To make long story short (find and read the thread if you’re interested) I set up to redo the implementation, moving most of the code that was generated at runtime into another, statically compiled class. Finally yesterday I had some time to actually start working on the implementation, but fixing bugs with code-gen at 1am proved to not be my strongest skill, so I finished the implementation today. Funny thing is, I...
Welcome to part two of my tutorial on Castle Dynamic Proxy. If you’re new to it, you might want to read part 1 as well, although if you’re new to the concepts behind dynamic proxy, you may actually want to read this part first, as it outlines the what, why and how of dynamic proxy.
After I re-read my initial post, I realized that I didn’t actually provide proper introduction in it. I mean, I made an introduction to the sample project we’re creating along this series, but I feel I should have provided more explanation for people who aren’t familiar...
I’ve been experimenting lately quite a lot with Castle Dynamic Proxy, creating prototype for a project I work on at work and I even implemented a small feature that was missing from it. Generally, Dynamic Proxy (DP from now on) is a great, lightweight framework, but it’s greatest downside is lack of documentation. It’s surprisingly logical a easy to use, but since there are almost no resources on the web, that could help you get started with it, I decided to give it a go, and start a small tutorial series of posts, that will introduce various features of DP...
I just got this test pass:
[Test]
public void BasicCase()
{
ProxyGenerationOptions options = new ProxyGenerationOptions();
options.Selector = new AllInterceptorSelector();
var target = this.generator.CreateInterfaceProxyWithTarget(
typeof(ISimpleInterface),
new SimpleClass(),
options,
new NoopInterceptor() ) as ISimpleInterface;
Assert.IsNotNull( target );
target.Do();
}
And here’s how Do proxy method looks like in...