Where do I put my Ioc (ninject) code in my service layer project? - asp.net-mvc-2

Question

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 layer(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
}
}

Answer 1

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.

Answer 2

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