Unity Configuration - Registration by Convention
To make container setup easier and less verbose, we are adding a new feature in Unity 3.0 – registration by convention.
What is the Registration by Convention feature?
This feature (also referred to as auto-registration) is intended to simplify your type registrations. Rather than specify each type mapping individually (lots of container.RegisterType<IFoo, Foo>()) , you can direct the Unity container to scan a collection of assemblies and then automatically register multiple mappings based on a set of rules that identify the types and their locations.
The following code shows example usage of the current implementation of registration by convention:
using (var container = new UnityContainer()) {
container.RegisterTypes(
AllClasses.FromAssembliesInBasePath(),
WithMappings.FromMatchingInterface,
WithName.Default,
WithLifetime.ContainerControlled);
}
What conventions are supported?
A convention must specify which available types should be mapped in the Unity container as well as how those type mappings are defined. Currently, the available conventions work by specifying the following rules:
1. Identify the list of assemblies to scan for types to be registered: you can provide your own list of assemblies, use only currently loaded assemblies, or use assemblies that reside in the base path of your application. You can further filter the list of types by names, suffixes or other predicates by using LINQ queries or extension methods. This first step results in a list of types to potentially register with the container. By the way, by default, all system assemblies will be skipped – you have to opt-in for them to be included. Note: you don’t need to start from our helper method for loading types. You can use any method to obtain an enumeration of types, even as simple as an array of literal types.
2. Optionally, specify which types (typically interfaces or abstract classes) you want the container to resolve to each of the types identified in step 1. Currently, conventions include:
a. Create mappings where the following naming convention is followed: type Foo and interface IFoo.
b. Map each type to all of the interfaces it implements.
c. Map each type to all of the interfaces it implements where those interfaces are in the same assembly as the type.
3. Optionally, specify whether to use a named registration. In this case Unity uses the type name as the name of the registration.
4. Optionally, specify which lifetime manager to use for the registrations.
5. Optionally, identify any members of the type that should be injected.
What about Windows Store Apps?
The registration by convention will also be supported by Unity for Windows Store Apps with some limitations enforced by the framework, such as you won’t be able to scan the loaded assemblies and you won’t be able to scan a particular folder, but you can assemblies packaged with the app.
What other specific conventions should we support?
As always, we seek your feedback on the new features. As we are finalizing the implementation of the registration by convention, it would be helpful to get your thoughts on the following:
1. Do you see a requirement for out-of-the-box automatic creation of mappings for abstract types as well as interfaces?
2. Do you see a requirement for out-of-the-box support for scanning other locations for assemblies? E.g. arbitrary folders.
3. In scanning the assemblies in some location, would you want to have a way of annotating specific assemblies with an optional attribute?
4. Do you see any requirement for context specific conventions? Such as ASP.NET MVC, WCF, etc. Or is Unity auto-wiring sufficient in these cases?
5. If you are providing injection members, some of those will be associated with the “from” type, but most will be associated with the “to” type. Do you see the need to be able to specify more fine-grained injection members, or is the support for “to” types sufficient?