Injecting dependencies on views is typically a bad practice. Views should simply get all the data they need from the controller through the view model. When you start adding dependencies to views you are entering a slippery slope. You should keep your
views as dumb as possible and prevent them from having any business logic and calls to services.
Because injecting dependencies on views is most of the time not the best thing to do, adding an
to the integration package doesn't seem a good thing to do. Simple Injector tries to promote best practices by omitting features, and proving such implementation out of the box does the opposite. Besides, plugging your own is easy
enough, as you've already shown.
One note about your implementation though. The AutowirePropertiesWithAttribute
from the documentation makes use of the
interface. This allows property injection that is deeply integrated with the framework. The
on the other hand is a legacy method from v1 and it doesn't integrate with
and the rest of the framework. It does implicit property injection (skips properties that can't be found without throwing) and injected properties don't show up in the
. Prefer not to use implicit property injection (especially using the
method) if possible. That means that the IViewPageActivator.Create
metod can simply look like this:
public object Create(ControllerContext controllerContext, Type type)
If implicit property injection is really needed (which should be very unlikely), you can always register a
that specifically enables implicit property injection for a certain set of types (such as MVC views).
>> btw: Is there a reason why "AutowirePropertiesWithAttribute" is not directly included in the SimpleInjector assembly
The design strategy of Simple Injector is to include a sensible set of operations that push developers into using best practices, but to support extendibility. In most cases developers should prefer using constructor injection instead of property injection.
When they feel the need to fall back to property injection, in many cases there's a problem with the design. For this reason property injection is not supported out of the box, but extension is possible using the
interface. Simple Injector not only tries to make it possible, but tries to make it easy to extend the framework by supplying a lot of code samples in the documentation (and in the CodeSamples project in source control).
But by explicitly not including these features in the framework itself we try to communicate best practices.