Stairway pattern implementation

Question

I came across "Stairway" pattern description in the "Adaptive code via C#" book and I don't really understand how this is supposed to be implemented:

(source)

So I have client assembly:

using ServiceInterface;

namespace Client
{
    class Program
    {
        static void Main(string[] args)
        {
            // Have to create service implementation somehow
            // Where does ServiceFactory belong?
            ServiceFactory serviceFactory = new ServiceFactory();
            IService service = serviceFactory.CreateService();
            service.Do();
        }
    }
}

Service interface assembly:

namespace Service
{
    public interface IService
    {
        void Do();
    }
}

And service implementation assembly:

using ServiceInterface;

namespace ServiceImplementation
{
    public class PrintService : IService
    {
        public void Do()
        {
            Console.WriteLine("Some work done");
        }
    }
}

And the question is: how to I get an IService object in the Client namespace? Where shall I place actual new PrintService() object creation? This can't be a part of ServiceInterface, because interface assembly doesn't depend on ServiceImplementation. But it also can't be a part of Client or ServiceImplementation because Client should only depend on ServiceInterface.

The only solution I came to is having Application assembly on top of it, which has references to all three (Client, ServiceInterface and ServiceImplementation) and injects IService into Client. Am I missing something?

Answer 1

Application entry points should be the composition root, as per Mark Seemann's excellent book on Dependency Injection. Here, the issue is more about Dependency Inversion, whereby both client and implementation should both depend on abstractions.

What that diagram doesn't show, but hopefully other parts of the book make clear, is that the entry point will naturally and necessarily reference everything that is needed to construct whatever are your resolution roots (controllers, services, etc.) But this is the only place that has such knowledge.

Bear in mind that it is sometimes ok for clients to 'own' the interfaces on which they depend: the interface ISecurityService might live in the Controllers assembly, the IUserRepository might live in the ServiceImplementations assembly, and so on. This is impractical when >1 client needs access to the interface, of course.

If you follow SOLID, you will naturally find that Dependency Injection is a necessity, but Inversion of Control containers are less of a priority. I find myself using Pure Dependency Injection (manual construction of resolution roots) more and more often.