Ninject with Windows Application

Question

I want to use Ninject in my Windows application and I want to know if there is best practices that I can do; strategies to find a balance between performance and maintenance.

The problem with Windows application and Web application is that in Web application, there is a scope easy to define that is the context but with Windows application, you have no scope that is easy to use form after form.

As example, I have a service that query the database. This service have a constructor and received a UnitOfWork. With Ninject, I can create a property marked as to be injected but if I do that, each time I will create this service, a new connection will be created to the database.

Just for this reason, I must manually create my services to control the number of connection created and no dependency injector can be used.

I have found that you can call the Inject method after created the service for inject dependencies but I'm sure I can use a better strategy.

Answer 1

With Ninject, you can have Ninject scope lifetimes of your injected dependencies to any object you want to provide (not just Singleton, Request, Thread, and Transient scopes).

From the Ninject Documentation Wiki:

You can also easily define you own scopes using the .InScope(object o) method.

You'll find some actual detail about how object scoping works in this Ninject Google Groups question & answer.

Answer 2

I finally found what I searching for.

Create a class that inherits from 'Ninject.Activation.Provider(of T)'

Overrrides the function 'CreateInstance'

Bind your interface with that 'Bind(Of [Your interface]).ToProvider([Your provider class])'

And now, you will be able to control each instance created that are associated with the specified interface.

Note that you can pass a type or an instance to the provider parameter of the Bind method. You can with an instance create a provider before binding your interfaces and use this provider in your code when you want to create a new instance.

The provider in conjunction with InScope allows great flexibility for each place where you want to have and instance of an object that can be injected automatically and have a determined scope.

Here is an example:

Public Interface IConnection

End Interface

Public Class Connection
   Implements IConnection

End Class

Imports Ninject

Public Class StandardModule
   Inherits Ninject.Modules.NinjectModule

   Public Property ConnectionProvider As ConnectionProvider

   Public Overrides Sub Load()
      Bind(Of IConnection).ToProvider(Me.ConnectionProvider)
   End Sub
End Class

Public Class ConnectionProvider
   Inherits Ninject.Activation.Provider(Of IConnection)

   Public Property Connection As IConnection

   Protected Overrides Function CreateInstance(ByVal context As Ninject.Activation.IContext) As IConnection
      Return Me.Connection
   End Function
End Class

Imports Ninject

Module EntryPoint
   Sub Main()
      Dim provider As New ConnectionProvider
      Dim standardModule As New StandardModule
      Dim connection As IConnection
      Dim kernel As New Ninject.StandardKernel()

      standardModule.ConnectionProvider = provider

      kernel = New Ninject.StandardKernel(standardModule)

      ' Here you should use a factory instead of create an instance directly but
      ' for demonstration, it show how an instance can be propagated to object created
      ' by NInject.
      provider.Connection = New Connection

      connection = kernel.Get(Of IConnection)()
   End Sub
End Module

Answer 3

This article by Ayende in MSDN Magazine is ostensibly about NHibernate, and mentions the word inject only once (and that only wrt AOP), but the phrasing of your question suggests to me it'll be great food for thought as you consider how to architect your app.