Tip - Generic robust approach for disposing both normal object as WCF proxy

Situation: a consumer object invokes a provider object to access functionality. The consumer operates against an interface to decouple it at compile-time from the actual implementation(s) of the provider side. The provider is runtime injected via Dependency Injection. After usage, the provider instance may have to be disposed, typical to release native resources (e.g. network or database connections). However, not all provider types need to have the IDisposable interface implemented. To prevent the consumer class from being cluttered with checks on IDisposable being implemented, I delegate this to an utility class in our framework. An example of the consumer usage is now:

In the implementation of the DisposableDecorator class the check is done whether the decorated/encapsulated object implements the IDisposable interface, and if so the Dispose method is propagated on to the encapsulated object. Simple, and it keeps the consumer code clean and focussed. However, when the encapsulated object is actually a WCF proxy, something special needs to be accounted for. The standard application of the using block may then result in an undesired effect. This occurs when an exception is thrown on the channel, putting the proxy in the Faulted state. When next trying to dispose the proxy, the closing of the proxy results in throwing a new CommunicationObjectFaultedException. The latter exception hides the original exception, which has put the proxy in the Faulted state. The solution is to first check whether the encapsulated object is a WCF proxy, and if so if it's communication state is Faulted. If that's the case, then invoke the Abort method on the proxy. Otherwise just maintain the Dispose propagation.

Dynamic updatable configuration in SharePoint list for Dependency Injection

Dependency Injection and Inversion of Control are 2 well-known and related design patterns to achieve flexibility and loose-coupling in your system architecture. Compile-time you decouple the consumer from the real provider(s) at interface level. At runtime the interface consumer is connected to a particular real implementation for the requested interface. The consumer is thus only dependent on the interface (= agreed behaviour), and transparent towards the concrete implementation. Dependent on situational factors, another implementation can be runtime provided to the consumer.

The responsibility for runtime instantiating and returning the correct particular implementation is typically delegated to a factory object. Multiple frameworks are available to provide a Dependency Injection (or IoC) container. Well-known are Spring.Net, Castle Windsor.

In a recent Proof-of-Concept I needed the flexibility to easily switch between different implementations of a service behaviour. Started with a stub when initially focussing on construction of the consumer (UI), followed by a variant with the business data stored in a SharePoint list in the local site, and finished with the ultimate version with the data stored in an external Lines of Business system, unlocked to the client via WCF. I prefer to name this plumping responsibility 'interface brokerage'. The signature of such a broker is simple:

I could have applied one of the available Dependency Injection frameworks. However, in this PoC evaluation I had some specific requirements which none of them seems to support all:

1. I want to be able to runtime change the configuration, and have this automatically picked up by the interface broker;


2. I want to share the same configuration entity accross multiple broker consumers (or rather, have only 1 single configuration entity to maintain);


3. Support different client contexts - SharePoint WebPart, WinForm, and also Silverlight control via the same interface broker implementation;


4. Be able to specify constructor parameters for the instantation of a service implementation (e.g. the name of WCF endpoint);


5. Be able to let the client access mode influence which implementation class is returned (for instance, to apply IsolatedStorage for the Silverlight control)
   

I decided to implement this specific brokerage functionality myself. And almost inevitable choose to apply a SharePoint list as configuration store. Benefits of this above a file based configuration are:

• It's possible to view and modify the configuration remotely within the browser; no need to have access to the server environment (is required to modify the web.config)


• Modification can be runtime determined and picked up by the broker (a web.config modification is also noticed, but results in a recycle of the application pool)


• Via the SharePoint List webservice the configuration can be accessed from any consumer context: SharePoint WebPart, WinForm, Silverlight [running at the client desktop], and even from non-Microsoft technologies like Flash, Java.

The following illustrations highlight the concepts of the resulting broker implementation:

  

Setup of the BrokerConfiguration storage

Example of a filled-in BrokerConfiguration

Code extract of reading in and parsing of the BrokerConfiguration

The essence of runtime determination + instantiating of requested interface provider (details and exception handling left out)

I hope that above gives you inspiration on the possibilities of utilizing the SharePoint functionalities within your system setup. Love to hear for what other system aspects one has applied the SharePoint functionalities...