asp.net mvc webform和razor的page基類區別

接觸過asp.net mvc的都知道，在傳統的webform的模式下，page頁面的基類是這樣聲明的：

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="ViewPage" %>

如果是partial view的話，則是這樣聲明的：

<%@ Control Language="C#" Inherits="ViewUserControl<dynamic>" %>

可以知道如果傳統的view的話是繼承於ViewPage這個類，如果是partialView的話則是繼承於ViewUserControl這個類。

為了證明我們的分析是否正確，我們看一下asp.net mvc的源碼，在源碼中有一個WebFormView類，這個就是支持我們傳統的web form的基類，我們來看一下它的RenderView是怎么實現的，順便這里提一下，WebFormView繼承於BuildManagerCompiledView，這個我們以后討論。

protected override void RenderView(ViewContext viewContext, TextWriter writer, object instance)
        {
            ViewPage viewPage = instance as ViewPage;
            if (viewPage != null)
            {
                RenderViewPage(viewContext, viewPage);
                return;
            }

            ViewUserControl viewUserControl = instance as ViewUserControl;
            if (viewUserControl != null)
            {
                RenderViewUserControl(viewContext, viewUserControl);
                return;
            }

            throw new InvalidOperationException(
                String.Format(
                    CultureInfo.CurrentCulture,
                    MvcResources.WebFormViewEngine_WrongViewBase,
                    ViewPath));
        }

我們可以清楚的看到，先對object instance判斷是否是ViewPage類型，如果為空則判斷是否是ViewUserControl類型，如果兩者都不是則拋出異常，由此我們可以得知，傳統的webform主要由這兩個基類組成。在傳統的asp.net webform是怎么的情況，還需要大家自己去論證。

好了，我們對asp.net mvc webform進行了分析，以后如果要重寫基類的話，只要根據具體的需要對ViewPage和ViewUserControl進行重寫就行了。

那么自從asp.net mvc 3.0以后微軟推出一個新的視圖引擎razor以后，他的基類結構是否發生變化？

事實的確是這樣的，當我們使用Razor引擎的時候，我們創建的.cshtml文件沒有了之前類似webform的頭部聲明：

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="ViewPage" %>

取而代之則是什么都沒有，這一時讓我們需要重寫基類的童鞋們摸不着頭腦，好了那讓我們用同樣的思路進行一下分析，razor的頭部聲明沒有，不代表他不繼承於基類，既然省略那么說明一個很直接的原因就是他們的view和partialview的頭部聲明應該是一樣的，所以微軟干脆就省去不寫了。那為了論證我們的猜想是否正確，我們看一下源碼。

同樣在源碼中有一個RazorView類，這個和WebFormView是對應着的，他同樣也繼承於BuildManagerCompiledView類，同理讓我們來看一下他的RenderView方法是如何實現的。

protected override void RenderView(ViewContext viewContext, TextWriter writer, object instance)
        {
            if (writer == null)
            {
                throw new ArgumentNullException("writer");
            }

            WebViewPage webViewPage = instance as WebViewPage;
            if (webViewPage == null)
            {
                throw new InvalidOperationException(
                    String.Format(
                        CultureInfo.CurrentCulture,
                        MvcResources.CshtmlView_WrongViewBase,
                        ViewPath));
            }

            // An overriden master layout might have been specified when the ViewActionResult got returned.
            // We need to hold on to it so that we can set it on the inner page once it has executed.
            webViewPage.OverridenLayoutPath = LayoutPath;
            webViewPage.VirtualPath = ViewPath;
            webViewPage.ViewContext = viewContext;
            webViewPage.ViewData = viewContext.ViewData;

            webViewPage.InitHelpers();

            if (VirtualPathFactory != null)
            {
                webViewPage.VirtualPathFactory = VirtualPathFactory;
            }
            if (DisplayModeProvider != null)
            {
                webViewPage.DisplayModeProvider = DisplayModeProvider;
            }

            WebPageRenderingBase startPage = null;
            if (RunViewStartPages)
            {
                startPage = StartPageLookup(webViewPage, RazorViewEngine.ViewStartFileName, ViewStartFileExtensions);
            }
            webViewPage.ExecutePageHierarchy(new WebPageContext(context: viewContext.HttpContext, page: null, model: null), writer, startPage);
        }

正如我們猜想的在RenderView方法中只看到一個WebViewPage的類，那么就說明Razor引擎的View和PartialView的基類進行了合並，其實我們可以通過擴展名也可以得知，因為razor的擴展名不管是view和partialview都是.cshtml，和之前webform的模式已經不同。

既然razor進行了合並，那么他們的頭部聲明肯定都是一樣的，所以微軟就省去了這個環節。

那么razor該如何重寫基類呢，如果聲明頁面頭部繼承關系呢？

同樣我們繼承於WebViewPage基類，然后在自己的view或者partialview的頭部進行如下聲明：

@inherits CustomWebViewPage

或者

@inherits CustomWebViewPage<CustomModel>

這樣就可以實現同的自定義實現了，不過這里需要提一點，由於WebViewPage是一個abstract類型的類，所以不能直接實例化，那么一點繼承的話，里面必須需要實現一個Excute方法。如果你聲明的CustomWebViewPage也是一個abstract類型，則不需要重寫，調用默認的實現就可以，但是如果不是則要自己去實現自定義的excute方法。