-
Notifications
You must be signed in to change notification settings - Fork 146
Dependency Injection
Cofoundry relies heavily on dependency injection, but does not depend on any specific DI framework. Instead you can integrate your favorite DI framework by installing one of the Cofoundry Dependency Injection packages
NB: Initially AutoFac is the only DI package we have a plugin for. Get in touch and let us know which other DI frameworks you'd like to see plugins for.
Your DI container needs to be initialized before initializing Cofoundry, which for a web project is done in the owin startup.cs file.
Each package will do this slightly differently so it's best to look at the documentation for that specific package, but it's usually just one line of code.
Your chosen DI plugin should also expose access to your chosen container so you can take full advantage of it's feature set.
Most Cofoundry services will automatically register themselves with the DI container, so you won't need to worry about registering types such as:
- Command & Query Handlers
- Custom Entity Definitions
- Background Tasks
- Startup Tasks
- User Areas
- Permissions
- "Registration" implementations (e.g. IRouteRegistration & IViewLocationRegistration)
- Plus many more
In fact, for some applications you may not need to worry about dependencies at all.
Cofoundry provides an abstraction for registering dependencies that it uses internally, but you can use it too if you want to take advantage of a standardized approach to registrations. This is also essential for allowing plugin developers to register types and override base level implementations.
To register a type, all you need to do is create a class that implements IDependencyRegistration
and add your registrations in the Register
method. Your types will automatically be registered at startup. You can implement as many of these registration classes as you like which can be handy for keeping your registrations and code modular.
using Cofoundry.Core.DependencyInjection;
public class ExampleRegistration : IDependencyRegistration
{
public void Register(IContainerRegister container)
{
container
.RegisterType<IMyService, MyService>()
.RegisterInstance<ExampleHelper>()
.RegisterAll<IExampleTask>()
.RegisterGeneric(typeof(IRepository<>), typeof(Repository<>));
}
}
Most registration methods have an optional RegistrationOptions
parameter which allows you to override an existing implementation. This is useful (particularly for plugin authors) if you want to override the base Cofoundry implementation with your own version.
using Cofoundry.Core.DependencyInjection;
public class ExampleOverrideRegistration : IDependencyRegistration
{
public void Register(IContainerRegister container)
{
var registrationOptions = new RegistrationOptions() { ReplaceExisting = true };
container.RegisterType<IMyService, MyService>(registrationOptions);
// OR use the static helper
container.RegisterType<IMyService, MyService>(RegistrationOptions.Override());
}
}
RegistrationOptions
has an additional priority property, but this should not normally be needed and should only be used as a last resort. The property is an integer but the RegistrationOverridePriority
enum is best used for predictable results:
- RegistrationOverridePriority.Low: Will override the default implementation and nothing more. Typically used inside the Cofoundry framework to override a default/empty implementation lower down in the framework.
- RegistrationOverridePriority.Normal: Default and the option to typically use in a plugin. Will override the existing implementation and any low level (typically default/placeholder) implementation.
- RegistrationOverridePriority.High: A higher level priority that should rarely be used (and never in the framework or plugins), but may be needed in a client application to override a plugin.