ASP. net mvc 3 service location, Part 10: controller Activator

Controller Activator

In MVC 1.0, we introduced Icontrollerfactory To allow better dependency injection of controller instances. We also provided thedefacontrocontrollerfactory, which created controller instances with activator. createinstance. Some of this is discussed in Part 2 Of this series.

We realized that defaultcontrollerfactory was actually doing two things: Turning the Controller name into the Controller type, and then instantiating the instance of that type. in ASP. net MVC 3, we 've split out the action of instantiating the Controller instance into a new service: icontrolleractivator. we have made the icontrolleractivator instance findable via the dependency resolver.

Disclause

This blog post talks about ASP. net MVC 3 beta, which is a pre-release version. specific technical details may change before the final release of MVC 3. this release is designed to elicit feedback on features with enough time to make meaningful changes before MVC 3 ships, so please comment on this blog post or Contact me If you have comments.

Implementing icontrolleractivator

The new icontrolleractivator signature is identical to Defaultcontrollerfactory. getcontrollerinstance Virtual method:

 
Public interface icontrolleractivator {icontroller create (requestcontext, type controllertype );}
 

Developers who previusly implemented icontrollerfactory by deriving from defaultcontrollerfactory just to override the getcontrollerinstance Method for dependency injection purposes shocould now implement icontrolleractivator instead.

Location: icontrolleractivator

This is a "singly registered" style service introduced in MVC 3. there is no static registration point for this service as its purpose is strictly to support dependency injection; as such, the only way to register an instance of this service is through the dependency resolver.

The logic in defaultcontrollerfactory was updated to consult the dependency resolver, calling getserivce (typeof (icontrolleractivator) and using the provided service when present. if there is no icontrolleractivator present in the dependency resolver, we will then ask the dependency resolver to create the concrete controller type by calling getservice (controllertype ). if the dependency resolver also fails to create the concrete controller type, we finally fall back to the MVC 2 behavior of using activator. createinstance to create the Controller type.

What's next?

In the final post of this series, we will discuss the new View page Activator Service.