Question

What is a proxy object in the Inversion of Control / Aspect-Oriented sense?

Any good articles on what a proxy object is ?
Why you would want to use one ?
And how to write one in C# ?

Answer 1

In general, a Proxy object is an object (instance of a class) that exposes the exact same public interface as a ‘real class’ but simply forwards all calls made to it’s members to the other real class. Proxy objects are used for a variety of reasons…

One purpose is to ‘pretend’ to be the real class so a client component (or object) can ‘believe’ it’s talking to the ‘real’ object, but inside the proxy, other stuff, (like logging, transactional support, etc.) is being done at the same time… Secondly, a proxy can be very cheap in comparson to the real object,. and often is used so that the real objects can be conserved (turned off or released to a pool to be used by other clients) when the client is not using them… The proxy stays ‘alive’ and the client thinks it still has a connection to the real object, but whenever it ‘calls’ the object, it is actually calling the proxy, which goes and gets another real object just to handle the call, and then releases the real object when the call is done.

As to Inversion of Control (IOC).. That refers to a common pattern (also referred to as Dependency Injection), where dependant objects inside of a class are ‘injected’ into an instance of the class, from client code, to control which version of a dependant object the instance will use… IOC can be used to inject a ‘Proxy’ object into a class where it thinks it is using the real object… The phrase Inversion of Control refers to the fact that when using this pattern, the decision as to which actual implementation is called is no longer under the control of the class making the call, but to the client of that class, when it injects an instance of a dependant object into the class to be used for this call.

Generally the term IOC is used with what is called an IOC Container, which is a class specifically designed to be responsible for creating instances of dependant classes based on loosely coupled information about those classes (Types) which it gets from some source other than hard-wired dependencies (most often, from some kind of configuration file). Generally, when you use an IOC container, you create an instance of it when the application starts, and then (by reading config data or whatever), you ‘register’ each of the classes (types) that the IOC container will be responsible for, with a key value. The key is often the abstract type or interface that all instances of this registration must implement). Then, in the normal operations of your application, where you might otherwise have new’d up an instance of one of these types, you call the IOC Container, and ask it for an instance instead, using the abstract type/Interface as the key. The IOC container then uses reflection or dynamic loading, (or whatever), to create an instance of whatever type has been ‘registered’ with that key. In this way, simply by changing configuration data, you can control the actual types used by the application, changing them in one environment or deployment location from those used in another.