IoC.Configuration¶
IoC.Configuration is a container agnostic configuration of dependency injection.
IoC.Configuration is a wrapper around popular IoC containers, with additional functionality (see below). Currently Ninject and Autofac are supported through the usage of Nuget extension packages IoC.Configuration.Ninject and IoC.Configuration.Autofac.
- Among other things, it allows:
- Specifying dependency injection configuration in XML configuration file, as well as in IoC.Configuration module classes, or third party IoC container modules (e.g., Autofac or Ninject modules).
- Easy switching between containers to use for service resolution (e.g., Autofac, Ninject).
In addition, the configuration file has sections for settings, plugins, startup actions, dynamically generated implementations of interfaces (see Autogenerated Services), etc.
All these functionality will be explained in corresponding sections, however here is a quick overview:
The dependency injection bindings are done using any combination of the following techniques:
- In IoC.Configuration module classes using chained methods, pretty similar to how it is done in popular containers, Ninject and Autofac.
Note
The IoC.Configuration module classes should either implement IoC.Configuration.DiContainer.IDiModule, or extend the class IoC.Configuration.DiContainer.ModuleAbstr, and override the method Load().
In module classes of one of popular IoC packages (such as Autofac or Ninject). These modules will be referred as native modules.
In XML configuration file. This method is the preferred way to configure the dependency injection, since it is the most flexible. XML configuration files have sections for type bindings, as well as sections for IoC.Configuration or native (i.e., Autofac, Ninject, etc) modules.
Note
IoC.Configuration has its own syntax for type bindings, which reminds the syntax used in Ninject. However, IoC.Configuration translates these type bindings into 3-rd party IoC container (e.g., Autofac, Ninject, etc) bindings .
Type resolutions are done using one of popular IoC containers (e.g., Autofac, Ninject, etc), through the usage of implementations of IoC.Configuration.DiContainer.IDiManager interface.
Note
Currently, two implementations of IoC.Configuration.DiContainer.IDiManager are availabe, Ninject and Autofac implementations). These implementations are in packages IoC.Configuration.Ninject and IoC.Configuration.Autofac.
The container (e.g., Autofac, Ninject) used by IoC.Configuration can be switched in XML configuration file. Here is an exert from IoCConfiguration_Overview.xml, that shows the usage of element diManagers to specify container for resolving types:
<!--
The value of type attribute should be a type that implements
IoC.Configuration.DiContainer.IDiManager
-->
<diManagers activeDiManagerName="Autofac">
<diManager name="Ninject" type="IoC.Configuration.Ninject.NinjectDiManager"
assembly="ninject_ext">
<!--
Use parameters element to specify constructor parameters,
if the type specified in 'type' attribute has non-default constructor.
-->
<!--<parameters>
</parameters>-->
</diManager>
<diManager name="Autofac" type="IoC.Configuration.Autofac.AutofacDiManager"
assembly="autofac_ext">
</diManager>
</diManagers>
- Sample Files
- XML Configuration File Schema
- XML Configuration Template
- IoCConfiguration_Overview.xml
- IoCConfiguration_GenericTypesAndTypeReUse.xml
- IoCConfiguration_autoService.xml
- IoCConfiguration_autoServiceCustom.xml
- IoCConfiguration_proxyService.xml
- IoCConfiguration_valueImplementation.xml
- IoCConfiguration_collection.xml
- IoCConfiguration_constructedValue.xml
- IoCConfiguration_classMember.xml
- IoCConfiguration_settingValue_ReferencingInConfiguration.xml
- Type Binding In Modules
- XML Configuration File
- Assemblies and Probing Paths
- Using Types in Configuration File
- Parameter Serializers
- Constructor Parameters
- Settings
- Specifying DI Manager
- Dependency Injection
- Modules
- Service Bindings
- Autogenerated Services
- Value Initialization Elements
- Predefined Type Value Initializer Elements
- object element
- injectedObject element
- collection element
- Example 1: Using collection element to specify constructed parameter value in service implementation
- Example 2: Using collection element to specify injected property value
- Example 3: Using collection element to specify a returned value for auto-generated method
- Example 4: Using collection element to provide a service implementation
- constructedValue element
- Example 1: Using constructedValue element to define a setting of type IoC.Configuration.Tests.ConstructedValue.Services.AppInfo
- Example 2: Using constructedValue element to define a service implementation
- Example 3: Using constructedValue element to specify a value returned in autoProperty element
- Example 4: Using constructedValue element to specify a value returned in autoMethod element
- Example 5: Using constructedValue element as a parameter value in another constructedValue element
- settingValue element
- Example 1: Using settingValue element to provide a service implementation
- Example 2: Using settingValue element in collection element
- Example 3: Using settingValue element to specify constructor parameter and injected property values
- Example 4: Referencing setting values in autoMethod and autoProperty elements
- Example 5: Referencing setting value in if element under autoMethod element
- classMember element
- Referencing non-static and non-constant class members
- Example 1: Using classMember to provide a service implementation
- Example 2: Using classMember in collection element
- Example 3: Using classMember to specify a returned value in autoProperty element
- Example 3: Referencing class member in if element under autoMethod element
- Example 3: Using classMember to call methods with parameters
- parameterValue element
- Startup Actions
- Plugins
- Additional Services Provided by IoC.Configuration
- Troubleshooting Configuration File Errors
- Loading IoC Configuration
- Resolving Types
- Application Integration
- Trouble-shooting