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...