Castle
There are 30 entries for the tag
Castle
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
One thing I don’t think I articulated clearly enough when announcing Castle Blog Aggregator, was that it comes with RSS feed. You may have noticed an RSS icon in your browser when browsing the aggregator site, but in case you didn’t here’s the direct link to the feed that you can use in your favorite feed reader. We’re also open to include other blogs in the feed, so if you blog about Castle, or know any good blogs about Castle project, let us know, either in the comments, or create a suggestion on Castle UserVoice...
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...
Mauricio, Castle newest committer, long time community member, and our man on StackOverflow.com, did a fabulous job at creating Castle blog aggregator. You now have one all things Castle RSS feed to subscribe to instead of hunting for content on many various blogs. It has some rules set so that it collects content from only a handful of blogs, skipping posts that are not related to its main topic. It comes mostly from committers and few other blogs that have proven in delivering high quality content. If you know any blogs that you think should be added to the...
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...
On the course of last few months, I’ve been working with Craig Neuwirt, on what I consider one of the coolest additions to Castle WCF Integration Facility. Problem As you probably know by default all WCF calls are synchronous – you make a request, under the cover WCF blocks your thread using a WaitHandle waiting for response, then it unblocks your threads making it look like a local call. This makes things simple for a programmer, who does not have to deal with synchronization, but it’s an overkill from scalability and performance perspective. There are also one...
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...
UserVoice is a very nice Web 2.0-ish web application, where users of different projects can speak their mind about projects in question. I like it for its clear interface, readability, and very low friction. Users can suggest improvements to projects, comment and vote on other suggestions. Project owners can give feedback to users, and official responses to suggestions. Some projects I use often like AnkhSvn, and StackOverflow use it as an official channel of feedback, and it seems to work very well. I thought Castle Project could use that too, so few days ago I created a site for...
Quiz Consider the following piece of code (it shows Castle MicroKernel, but since Windsor is built on top of MicroKernel, it works the same way): IKernel kernel = new DefaultKernel();
kernel.AddComponent("sms", typeof(IAlarmSender), typeof(SmsSender));
kernel.AddComponent("email", typeof(IAlarmSender), typeof(EmailSender));
kernel.AddComponent("generator", typeof(AlarmGenerator));
AlarmGenerator gen = (AlarmGenerator) kernel["generator"];
Considering AlarmGenerator has a dependency on IAlarmSender, which one of two registered components will it get?
The answer is: the first one.
In this case we registered SmsSender first, so it will get injected. If we switched the order of registration, EmailSender would get injected. It does...
Patrik Hägne has an interesting post on removing compile time dependencies between assemblies, while still reaping benefits of using fluent interfaces to bootstrap AutoFac container (go read it, I’m not going to reiterate what Patrick wrote) using MEF. It inspired me to do similar thing for Castle Winsor. I created a simple solution with 3 project. One is the main application entry, which also holds a MefInstaller which we’ll talk about in a second. Second one: Services, contains interfaces that our application rely on. Impl contains implementation of these interfaces. Pretty simple huh? The...
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 ...
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...
I really need to come up with filtering strategy, or get some long vacations to go thorough all the good stuff that’s there. Any ideas? How do you handle the discussion groups? Technorati Tags: ALT.NET, Castle, XP, NHibernate