Reputation: 9377
I'm having a Web which reference a Data and Entity layer. Now I want to expand my solution with a Console app that will do some stuff related to the Database, and therefore also have reference to both the Data and Entity layer. In my Data and Entity layer I'm using Dependency Injection all over the place, and was thinking whether I need to declare all the bindings for those injections once more (like in my web app) - or I can share them somehow, so that my Web and Console app uses the same bindings?
My first thought was to create a common library with ALL my bindings and then only call those I needed.. but that lead to unessecary references to a shit load of assemblies.
In short: How can I declare my dependency injection bindings once and use them both in my Web app and in my Console app?
Any suggestions?
Upvotes: 1
Views: 428
Reputation: 32725
If your concern is to keep your business logic assemblies free of Ninject modules you can alternatively add them to own assemblies e.g. EntityBindingModule.dll and tell the kernel to load all of them in your bootstrapper:
kernel.Load("*BindingModule.dll")
This way it's just a question of deployment which bindings are added.
NOTE: This requires some kind of convention between the assemblies that are loaded by the bootstrapper and the actual name of the assemblies. In the example above it is that these assemblies end with BindingModule.dll.
Upvotes: 5
Reputation: 10564
I think a layout similar to this could work:
Console (Just Data)
|
|--> Ref: Data
|--> Ninject: Load DataModule
Web (Both Data and Entity)
|
|--> Ref: Data
|--> Ref: Entity
|--> Ninject: Load DataModule, EntityModule (should wire up the bindings)
Data
|
|--> Ref: Common
|--> Data.cs
|--> DataModule.cs -> Bind<IData>().To<Data>()
Entity
|
|--> Ref: Common
|--> Entity.cs
|--> EntityModule.cs -> Bind<IEntity>().To<Entity>()
Common
|
|--> IData.cs
|--> IEntity.cs
The Ninject documentation details how you would use a module in code.
Upvotes: 1