My Book

Mastering Ninject for Dependency InjectionMastering Ninject for Dependency Injection, in a simple and easy to understand format, demonstrates how Ninject facilitates the implementation of Dependency Injection to solve common design problems of real-life applications.
Dependency injection is an approach to creating loosely coupled applications. Maintainability, testability, and extensibility are just a few advantages of loose coupling. Ninject is a software library which automates almost everything that we need in order to implement a dependency injection pattern.

This book is for all software developers and architects who are willing to create maintainable, loosely coupled, extensible and testable applications. Since Ninject targets .NET platform, this book is not suitable for software developers of other platforms. You should be comfortable with Object Oriented principals and have a fair understanding of Inheritance and Abstraction. Being familiar with design patterns and general concept of Unit Testing is also a great help but no knowledge of Dependency Injection is assumed.

The book was published by [PACKT] publishing in 2013 and it is available in both e-book and printed formats on most of the online book retailers including Amazon.comO’Relly.comGoogle PlayiTunes and Safari Books.


7 thoughts on “My Book

  1. Greetings. Does this book teach implementing Ninject in Windows Service? Thanks in advance, Krishna.

  2. Hi Krishna,

    In terms of implementing Ninject, Windows services are similar to Console applications and the “composition root” is in the Main() method. Your Main() method in a Windows service should look like this:

    static void Main()
        using (var kernel = new StandardKernel())
            // In this example I used a single binding, 
            // but in real life applications, a binding convention is recommended here.
            ServiceBase[] ServicesToRun = kernel.GetAll().ToArray();

    Console applications, Composition roots, and binding conventions are all covered in the book.

    • Thanks for a quick response, Daniel. I bought the book and I am loving it so far, good job sir. But, I am still stuck at one place, if you can help me there, I’d really appreciate it.
      My question is: My Windows Service project is a start up project in a .Net solution. This project has dependency of other .Net projects (like database project, business logic project, contracts project, etc) in same .Net solution. I have used IDependencyResolver (a member of System.Web.Http.Dependencies) in .Net Web API to resolve dependencies, but I cannot use that interface in Windows Service.

      So, do you have any suggestion on how to resolve this multi project dependency? I appreciate your guidance. If you can’t help without looking at my code, I can try providing a simplified version of my code to you as well.


      • Hi Daniel. I have found one solution, it may not be THE solution, but it works for me. Instead of having a dependency resolver in my root project, i.e. windows service project, and then having all IoC (for NinjectModule classes) in all the sub-projects, I did this and it worked:

        1. I added all the project references to the root project.
        Before this I had nested references, like data project reference was only in ESB project. ESB project reference was only added in business logic project. Business logic project was only added in root project. Now, all projects (data, ESB, Business Logic, etc) are added to root project.

        2. I removed all IoC folders from sub projects, removed all NinjectModule classes from all those projects.

        3. Kept only one IoC folder, only one NinjectModule class in root project, and declared all the bindings here, including even for those sub-projects. Like this:

        public class ListnerNinjectModule : NinjectModule
        public override void Load()

        This is a little different approach than I am used to in MVC and in Web APIs, and it works for now.

        Thanks again for your help,

  3. Hi Krishna,

    Sorry for the late answer. First of all none of your projects should know anything about your IoC container, except the one which has your composition root. So you made the right decision to remove Ninject modules from your other projects. Adding a reference to all project in the root of your application is not a bad idea but it is not necessary. If you use conventional binding, you simply need to have the dll of your projects in the bin directory and Ninject scans all of the assemblies even if you haven’t added a project reference. However adding a project reference is the easiest way to make sure you’ll have all your binaries in your bin directory after every build.

    • No problem, appreciate your responses. What you just said, that makes total sense. Thanks again, Krishna.

Leave your comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s