Dependency Injection (DI) is a design pattern in Object Oriented Programming where the dependencies of a class are injected at runtime. These dependencies are mostly injected through a constructor (Constructor DI) or a property (Property DI). One of the main advantages of DI is it simplifies unit testing by allowing to inject mock dependencies in the place of real classes. In some cases we should have a default constructor in classes like in ASP.NET MVC controllers, WCF services etc. In WCF the service classes should have a default constructor else the framework will throw a runtime exception. To solve this problem developer ends up writing two constructors one is default and the other one is parameterized. The default constructor is used by the framework and the parameterized one is used by developers at the time of unit testing.

Although having two constructors suffice the job but we are violating the principles of dependency injection by instantiating the concrete classes in the default constructor. WCF is a highly extensible framework and fortunately it provides extension points even to customize the service instantiation. It looks like some of the DI containers simplify our job of customizing service instantiation by providing their own custom service host factories.

In this article we are going to see about the WCF extension point IInstanceProvider that allows us to customize the service instantiation and how the DI container Castle Windsor simplifies the task of creating services without default constructor through its new integration facilities.

WCF Web API is Microsoft's answer for creating RESTful services. Currently it is in preview state and you can download the binaries from here. For the people who are not aware of RESTful services, a RESTful service is a simple web service implemented using HTTP and that can be communicated using the normal GET, POST and other HTTP methods. Exposing a class as a RESTful service makes it easily accessible by wide variety of browsers and devices. In WCF Web API the REST service class is typically called as a resource and the format in which they exchange data is called as media type (ex. XML, JSON etc).

The WCF Web API uses the same routing module used in ASP.NET MVC to route the incoming requests to particular service class methods. In this small article I’m going to tell you how we can make the service to return data in JSON media-type.

In Service Oriented Applications there are many cases we need an intermediate software between clients and services that bypasses the communication between them. The intermediate software is typically called as a router. Some of the well-known examples where we need a router are protocol mapping (ex. the service is exposed to tcp while the clients expects http), load-balancing (ex. distributing messages to services running in different servers in a round-robin fashion), content-based routing (routing messages to different services based upon the message content) etc.

WCF 4.0 ships with a new service called Routing Service that makes developers life so easy by separating out the routing logic from the clients and services. The nice thing about the Routing Service is it is so easily pluggable and configurable. This Routing Service is available under the new assembly System.ServiceModel.Routing.

In this article I’m going to describe about how we can achieve content-based routing using the WCF Routing Service.