-
Notifications
You must be signed in to change notification settings - Fork 529
Conventions Based Binding
WIP: This page has not been updated for Ninject2, conventions based binding has been change quite drastically since Ninject 1, much is now implemented in the extension Ninject.Extensions.Conventions
The contextual binding system can also be used to implement a conventions-based binding system, if you prefer conventions over declarative configuration. Many people prefer to keep infrastructure dependencies like attributes out of their code — this can serve to keep the codebase clean, at the expense of clarity for newcomers.
For example, let’s say you have two sources for configuration in your application, a LocalConfigurationSource
that loads configuration information from a local file, and a RemoteConfigurationSource
that loads configuration from a remote database. Services that depend on configuration information will need one or the other of these services to set up configuration. Let’s say you have a consuming service that loads some of its configuration from the local source, and some from the remote source:
public class Service
{
public Service(IConfigurationSource remoteConfig, IConfigurationSource localSource)
{
//...
}
}
In order to get Ninject to resolve these dependencies and call this constructor, you will need to declare bindings that differentiate between the two implementations of IConfigurationService
. If you favor a declarative approach, you could create [Remote]
and [Local]
attributes, and use them to decorate the individual constructor arguments:
public class Service
{
public Service([Remote] IConfigurationSource remoteConfig, [Local] IConfigurationSource localSource)
{
//...
}
}
Then your bindings would look like this:
Bind<IConfigurationSource>().To<RemoteConfigurationSource>().WhereTargetHas<RemoteAttribute>();
Bind<IConfigurationSource>().To<LocalConfigurationSource>().WhereTargetHas<LocalAttribute>();
However, if you’d rather not have to put the attributes in your constructor, you can rely on a conventions-based approach instead. For example, you can create a rule that says that if you want an instance of RemoteConfigurationSource
, your argument has to begin with “remote”, and if you want an instance of LocalConfigurationSource
, it has to begin with “local”. To do this, you would create bindings like this:
Bind<IConfigurationSource>().To<RemoteConfigurationSource>().Only(When.Context.Target.Name.BeginsWith("remote"));
Bind<IConfigurationSource>().To<LocalConfigurationSource>().Only(When.Context.Target.Name.BeginsWith("local"));
By using these bindings, your consuming service could have a constructor with no attributes, as shown in the first code example on this page.
Licensed under Apache 2 License
Contents
- Home
- Why Use Ninject
- Getting Started
- Dependency Injection By Hand
- Dependency Injection With Ninject
- Injection Patterns
- Multi Injection
- Object Scopes
- Modules and the Kernel
- Providers, Factory Methods and the Activation Context
- The Activation Process
- How Injection Works
- Contextual Binding
- Conventions-Based Binding