Basically, we have the problem today that a controller may require a special service for basic operation. For example, it may require a special set of Formatters, IActionValueBinder, or other parameter binding services. It may have wacky actions that require its own special ActionSelector to find and serve. But we don’t have a good way to fulfill this need. This was previously accomplished via a smattering of techniques (HttpControllerConfiguration, DefaultActionValueBinder.GetFormatters(), etc). We’re trying to remove the patchwork of hacks and have a single unified way to do this.
This is mainly rallying around existing concepts and killing off half-baked concepts:
1. HttpControllerDescriptor was already our per-controller config, but now we’ll empower it with its own services container.
2. The controller services normally just “shadows” the default services. But it also has copy-on-write semantics so that you can override individual services on it. You can completely replace services inherited from global config / DI, or you can append to that list. (this exercise also forced us to clarify our notion of single vs. multiple service in the DefaultServices).
3. Generalize HttpControllerConfigurationAttribute to have an Initialize() function so that you can fully initialize a controller descriptor. Before, you could only set 4 properties that were available during the attribute.
4. Things that used to take a HttpConfiguration can now take a HttpControllerDescriptor if they want per-controller services. Parameter binding is a prime example.
5. Remove DefaultActionValueBinder.GetFormatters() and use the controller services facilities instead.
To do initialize, we need to execute some Initialize method that’s shared across controller types (just like when initializing the HttpConfiguration). We’re looking at pointing to the function via an attribute on the controller type.
Here’s a sample usage example:
This is mainly rallying around existing concepts and killing off half-baked concepts:
1. HttpControllerDescriptor was already our per-controller config, but now we’ll empower it with its own services container.
2. The controller services normally just “shadows” the default services. But it also has copy-on-write semantics so that you can override individual services on it. You can completely replace services inherited from global config / DI, or you can append to that list. (this exercise also forced us to clarify our notion of single vs. multiple service in the DefaultServices).
3. Generalize HttpControllerConfigurationAttribute to have an Initialize() function so that you can fully initialize a controller descriptor. Before, you could only set 4 properties that were available during the attribute.
4. Things that used to take a HttpConfiguration can now take a HttpControllerDescriptor if they want per-controller services. Parameter binding is a prime example.
5. Remove DefaultActionValueBinder.GetFormatters() and use the controller services facilities instead.
To do initialize, we need to execute some Initialize method that’s shared across controller types (just like when initializing the HttpConfiguration). We’re looking at pointing to the function via an attribute on the controller type.
Here’s a sample usage example: