Ninject modules or organising wiring up dependencies

Question

I've started playing with Ninject and from a screencast it states the following is how you set up a binding:

class MyModule : StandardModule {

    public override void Load() {
        Bind<IInterface>().To<ConcreteType>();
        // More bindings here...
    }
}

This is all very good.

However suppose you have one hundred objects used in an application. That would mean this would have one hundred bindings. Is this correct?

Secondly, I presume that given such an application it may be split into subsystems such as GUI, Database, Services and so on.

Would you then create a custom module for each subsystem which in turn would be:

• GUIModule
• DatabaseModule
• ServiceModule
• ...

For each module you'd have the correct bindings that they required. Am I on the right page here?

Finally would this binding all occur in Main or the entry point for your application?

Answer 1

However suppose you have one hundred objects used in an application. That would mean this would have one hundred bindings. Is this correct?

One hundred registered components, yes, but not necessarily registered one by one. There's a Convention extension for Ninject that allows you to scan assemblies and register types based on some defined rules. See this test as an example.

Would you then create a custom module for each subsystem

Again, not necessarily. You might just want to register all your repositories (just to name something) in a single convention registration.

For each module you'd have the correct bindings that they required.

As with any "module" (be it assembly, class, application) the concepts of coupling and cohesion apply here as well. It's best practice to keep coupling low (don't depend too much on other modules) and cohesion high (all components within a module must serve towards a common goal)

Finally would this binding all occur in Main or the entry point for your application?

Yes, see this related question.