Question

Before I start I must say that I maybe biting more than I can chew but I am in a desperate learning rampage and I need a lot of help.

I am coding an exercise taking the samples from two books:
1. Dependency Injection in .Net by Mark Seemann
2. Professional ASP .Net Design Patterns by Brian Egan and Steve Valenzuela

The exercise is implementing the Request/Response messaging pattern using WCF as the service layer AND using Dependency Injection from a Composition Root in the client application.

From 2:
In the exercise, for the service layer I have five class libraries:
– Contracts: with the interfaces for the services’ contracts.
– Data Contracts: with all the objects that are decorated with the DataContractAttribute
– HttpHost: the host for the WCF services. This library contains all the svc files
– ServiceProxy: this library manually implements the services’ proxys for the clients to use
– Services: contains the implementations of the services.

From 1:
I want to test this exercise with both a console and an ASP .Net MVC clients so the composition roots are the Main method for the first one and the Global.asax and custom controller factory combination for the second one.

So my questions are:

1. If the composition root is being implemented on the client, do I have to provide yet a custom implementation for the ServiceHostFactory, ServiceHost, and IInstanceProvider in WCF? Wouldn’t that make me have two composition roots?
2. If (hopefully) I only need the composition root in the client, where do I create the constructors with the dependencies? In the service’s implementation or in the service’s proxy or in both?
3. How should the object hierarchy be configured? I want to first use Poor Man’s DI and once that’s running to incorporate Structure Map as the IoC container.

Thank you so much for your help.

This is the code I have so far (I’m not including the service contract nor the data contracts):

Service Implementation:

namespace Exercise.Services
{
    public class PurchaseOrderService : IPurchaseOrderService
    {

        private readonly IPurchaseOrderFacade PurchaseOrderFacade;

        public PurchaseOrderService(IPurchaseOrderFacade purchaseOrderFacade)
        {
            PurchaseOrderFacade = purchaseOrderFacade;
        }

        public PurchaseOrderResponse CreatePurchaseOrder(PurchaseOrderRequest purchaseOrderRequest)
        {
            var purchaseOrder = PurchaseOrderFacade.CreatePurchaseOrder(purchaseOrderRequest.ToPurchaseOrder());

            var purchaseOrderResponse = purchaseOrder.ToPurchaseOrderResponse();
            purchaseOrderResponse.IsSuccessful = true;

            return purchaseOrderResponse;
        }

        public PurchaseOrderResponse UpdateState(PurchaseOrderRequest purchaseOrderRequest)
        {
            var purchaseOrder = PurchaseOrderFacade.UpdateState(purchaseOrderRequest.ToPurchaseOrder());

            var purchaseOrderResponse = purchaseOrder.ToPurchaseOrderResponse();
            purchaseOrderResponse.IsSuccessful = true;

            return purchaseOrderResponse;
        }
    }
}

This is the proxy for the client:

namespace Exercise.ServiceProxy
{
    public class PurchaseOrderProxy : ClientBase<IPurchaseOrderService>, IPurchaseOrderService
    {
        public PurchaseOrderResponse CreatePurchaseOrder(PurchaseOrderRequest purchaseOrderRequest)
        {
            return base.Channel.CreatePurchaseOrder(purchaseOrderRequest);
        }

        public PurchaseOrderResponse UpdateState(PurchaseOrderRequest purchaseOrderRequest)
        {
            return base.Channel.UpdateState(purchaseOrderRequest);
        }
    }
}

Answer 1

Every application has its own Composition Root. The WCF service is an application on its own, and will means it has its own Composition Root.

Or let me put it differently, the clients shouldn’t dictate how the service is going to build up its object graphs and it’s hard to imagine since the service will live in its own process and most often on a separate machine.

This doesn’t mean multiple applications (in the same solution for instance) can’t share a part of the DI configuration, but the object graphs of the client and the service will probably even have little in common (they don’t share much of the same code base). You will see much more sharing of the configuration, when you’re building both a WCF service and a Windows Service that use the same business layer, for instance. But even in that case, although they perhaps share a great part of the DI configuration, we’ll still say that they have their own Composition Root.