Where do I put my Ioc (ninject) code in my service layer project?

I have 3 project files

webui - controllers and views
framework - service layer and repos
tests- unit tests

So how I see it is that my controllers will only talk to my service laye开发者_运维问答r(that contains my business logic). The service layer will talk to the repos and get database data.

My repo will just talk do the database and return data.

Now if I want to unit test this I need to have fake service layers and fake repositories.

this way I can test the controllers in isolation and the service layers in isolation.

So where do I put my ninject code in my framework class library so that I can use it with my service layer?

Edit

Steven are you saying I should be doing something like this

//setup ninject in global aspx with mvc extension

// now bind the stuff

private class SportsStoreServices : NinjectModule
        {
            public override void Load()
            {

                Bind<IAdminService>().To<AdminService>();
                Bind<IAdminRepo>().To<AdminRepo>();
            }
        }

// controller

public class AccountController : Controller
    {
        //
        // GET: /Account/

   private IAdminService adminService;

 public AccountController(IAdminService adminService)
        {
   this.adminService = adminService;
 }


        public ActionResult Login()
        {
            var getAllAdmins = adminService.GetAllAdmins();
            return View();
        }

    }

// Service Layer

public class AdminService : IAdminService
{

   private IAdminRepo adminRepo;
   public AdminService(IAdminRepo adminRepo)
   {
      this.adminRepo = adminRepo;
   }

   public List<Admins> GetAllAdmins()
   {

       return adminRepo.GetAllAdmins();
   }   

}


//Repo
    public class AdminRepo : IAdminRepo
    {
       public List<Admins> GetAllAdmins()
       {
          // some query to get all admins
       }
    } 

---

When you follow the Dependency Injection pattern correctly (and completely) the only place you need to reference your IoC container is in your application root (in your case your web project). For MVC you would typically have a ControllerFactory that knows how to create new controllers using your particular IoC framework. Your controllers will be designed around constructor injection so your IoC framework is able to automatically inject all the dependencies. You will typically use constructor injection throughout the whole project. This allows you to let the rest of your code stay ignorant of the choosen IoC implementation.

For unit tests you would normally use constructor injection to manually inject the dependencies. This saves you from having to configure your IoC framework for your unit tests. Using an IoC library in your test project is painful, because you often want different dependencies to be returned per test case and testing frameworks often run your tests in parallel. So best is to not use any IoC framework in your tests, but call the constructor of a type under test yourself.

The trick for unit tests with DI is to keep your unit tests maintainable. You can do this for instance, by extracting the creation of a type under test into a factory method. This allows you to call such a constructor just in one place in your code. When the constructor changes, you would will have to change your test code in one place. I learned a lot about writing maintainable unit tests by the book The Art of Unit Testing. I can recommend it.

---

At project the DI should be in the place where the object composition can Happen.. For instance in WCF service Project we can do it using IInstanceProvider,IN asp.net Global.asax . Ground rule:Make sure the DI is the application start up point