如果深入探討有關編寫移動設備網站的常識性考慮因素，會發現其中有一種內在矛盾。一方面，客戶在其 編寫應用程序和網站的方法中強烈要求（或樂於要求）移動優先。另一方面，同一些人又經常稱贊 CSS 媒體 查詢和流體布局。我所發現的矛盾在於經常利用 CSS 媒體查詢和流體布局並未在其他內容之前優先處理移動 方面，它不是一種移動優先的方法。在本文中，我將介紹如何使用服務器端邏輯為給定設備呈現最佳的顯示效 果，並介紹 ASP.NET MVC 4 的一種新功能，稱為顯示模式。
問題不在於 CSS 媒體查詢作為一種技術。問題甚至也不在於自適應 Web 設計 (RWD) 作為 CSS 媒體查詢 的支持方法 — 雖然不是這項技術啟發性的宗旨所在。那麼，怎樣將使用 CSS 媒體查詢和流體布局變為一種 “移動優先”的方法？在用於推廣此方法的口號中即可發現端倪： 一個基本代碼可為多個視圖服務。在這個 角度上，使用 CSS（一種客戶端技術）在視圖之間切換，而使用 JavaScript 在 CSS 無法勝任時進一步調整 視圖。
在我看來，此方法中的基本做法是為所有設備提供相同內容，只調整頁面布局以適合屏幕大小。因此，可 能無法向用戶提供最佳的體驗。我認為，您應在合理的情況下力求僅有一個基本代碼（Web API 的共同基礎） ，但一定要重點關注要支持的每類設備的具體使用情況。“移動”一詞如今已變得意義狹窄，被智能手機、平 板電腦、筆記本電腦和智能電視等多種類型的設備取代，更不用說眼鏡顯示器和智能手表等可穿戴設備。
大約一年前，我在這個專欄中展示了一種在開發 ASP.NET MVC 網站時采用的服務器端方法： 用於為 所支持的每類設備創建臨時視圖（“移動站點開發：標記”msdn.microsoft.com/magazine/jj133814）。 我當時在 ASP.NET MVC 3 的環境中這樣做。ASP.NET MVC 4 完全勝任這項任務，它具有前面提到的顯示模式 ，可使用它輕松實現為給定設備提供最佳視圖和內容的服務器端邏輯。為了切實有效，此方法要求您盡可能多 地了解請求設備的功能。但是，除了有關屏幕大小和當前方向的基本信息外，在客戶端上檢測不到其他內容。 然後，需要采用設備信息的服務器存儲庫。
在 ASP.NET MVC 4 中引入顯示模式
在我開始深入探討顯示模式之前，請讓我事先聲明，這篇文章（以及顯示模式技術本身）主要涉及生成一 個獨一無二的新站點，其中將同一 URL 動態綁定到不同的視圖。如果您已有網站，要提供一個為某些（移動 ）設備優化的附屬網站，那完全是另一個話題。您仍可將本專欄作為生成附屬網站的指南，但與現有父網站統 一 URL 需要使用其他工具。
在 ASP.NET MVC 4 中，顯示模式是一項系統功能，該功能擴展視圖引擎的傳統行為，使後者可選取最適合 請求設備的視圖文件。在前面提到的 ASP.NET MVC 3 文章中，我為此使用了自定義視圖引擎。在該解決方案 中，我還只能使用 Razor 視圖。通過顯示模式，控制器方法仍將調用，比如說，一個名為 Index 的視圖，如 果已知請求設備為某種移動設備，則 ASP.NET MVC 運行時將改為選取一個名為 index.mobile.cshtml 的視圖 文件。
這是一個大好消息，因為這表示網站仍可只有一個基本代碼。只需為要支持的每類設備添加額外的 CSHTML 視圖文件。為了開始使用顯示模式，我們來看圖 1 中的代碼示例。
圖 1：支持的顯示模式的標准列表
<h2>
Display Modes currently active
(@DisplayModeProvider.Instance.Modes.Count mode(s))
</h2>
<ul>
@{
foreach(var d in DisplayModeProvider.Instance.Modes)
{
<li>@(String.IsNullOrEmpty(d.DisplayModeId)
?"default" :d.DisplayModeId)</li>
}
}
</ul>
圖 1 中代碼中的頁面顯示支持的顯示模式的標准列表。圖 2 顯示由該頁面生成的輸出。
查看本欄目
圖 2：顯示模式的默認列表
