In ASP.NET MVC, it’s common for views to be compiled into classes. In MVC 1.0, we shipped the WebFormViewEngine as the default view engine, which allowed the user to write views using the familiar <% %> syntax from ASP.NET WebForms. The first time the view is rendered, the view file goes through a code generation step, which is compiled into a class. The WebFormViewclass is responsible for creating and executing the class that resulted from the view.
In ASP.NET MVC 3, we introduced a new Razor view engine. Like the WebForm view engine, the .cshtml and .vbhtml files from Razor go through a code generation step at run-time which compiles down into classes. The RazorView class is the Razor view engine counterpart to the WebFormView class.
We have introduced a new base class (BuildManagerCompiledView) and a new service (IViewPageActivator) which is responsible for instantiating instances of the view classes that were compiled from the view files. We have made the IViewPageActivator instance findable via the dependency resolver.
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.
When we introduced the new Razor view engine, it was clear that there was a lot of common code between the infrastructure classes of our two view engines; namely, the WebFormView and RazorView (which both implement the IView interface) had significant shared code that was centered around BuildManager.
In the ASP.NET runtime, BuildManager is the class that is responsible for converting view files (like .aspx and .ascx files in WebForms, and .cshtml and .vbhtml files in Razor) into the underlying classes using code generation. BuildManager uses build providers to do most of that transformation work (which is outside the scope of this blog post). The important takeaway is that we extracted a common base class for the two view classes: BuildManagerCompiledView. The logic which creates view page class instances was centralized into this class, and the new IViewPageActivator service was introduced to allow pluggability of the creation of the view page classes.
Developers which are creating view engines which use build providers and BuildManager to convert view files into classes can take advantage of this new base class for their implementation(s) of the IView interface.
The new IViewPageActivator interface contains a single method for creating a view page instance:
public interface IViewPageActivator {
object Create(ControllerContext controllerContext, Type type);
}
Given the controller context and the view page class type, implementers of this interface must create the view page instance.
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 BuildManagerCompiledView consults the dependency resolver, calling GetSerivce(typeof(IViewPageActivator)) and using the provided service when present. If there is no IViewPageActivator present in the dependency resolver, we will then ask the dependency resolver to create the concrete view page type by calling GetService(viewPageType). If the dependency resolver also fails to create the concrete view page type, we finally fall back to the MVC 2 behavior of using Activator.CreateInstance to create the view page type.
This is the end of the road for MVC 3 Beta. We believe we are now reasonably feature complete for MVC 3 and dependency resolution. If there are specific areas where you wish the framework would better enable dependency resolution, please don't hesitate to discuss them on the MVC Forums.
Thanks for reading!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。