如何使用Microsoft技術棧

        英文原文：What to Use on the Microsoft Stack

        Microsoft 技術棧最近有大量的變遷，這使得開發人員和領導者都想知道他們到底應該關注哪些技術。Microsoft 自己并不想從官方層面上反對 Silverlight 這樣的技術，相對而言他們更喜歡讓這種技術慢慢淡出人們的視線，否則局面可能會更加混亂。如果你想了解該問題的答案，那么可以查看“.NET 業務應用程序技術指南”這個小有名氣的文檔。該文檔發布于去年早些時候，它深入探討了 Microsoft 打算在哪些領域付出努力，我們應該回避哪些技術等內容。

        下面這個概要圖是我們探索 Microsoft 及其相關技術的一個很好的起點。

        盡量早日放棄 Silverlight 和 Flash

        雖然 WinForms 和 Web 表單這些舊的 .NET 技術依然占有一席之地，但是 Silverlight 和 Flash 這樣的 RIA 容器絕對是出局了。正如下面圖5-15 所展示的，Microsoft 并不想空等著 Silverlight 5 所計劃的 10 年生命周期。他們已經打算在 2015 年底放棄 RIA 容器。

        高端應用程序更傾向于完全使用本地技術；而低端應用程序則期望 HTML5 的能力持續發展。盡管沒有將開發人員推向具體的某一種技術，但是對于這種轉變我們必須要注意的事情是：

• 如果你正在過渡到本地應用，那么你可以以生來就可以在任何 Windows 設備上運行的 XAML/.NET 作為目標，這樣你就能夠利用自己已有的技能甚至是代碼了。可移植類庫還允許你在不同的平臺之間共享類庫，包括 Silverlight。
• 對于基于瀏覽器的 HTML5 應用而言，Microsoft 提供了主要的工具和框架，它們能夠幫助你基于最新的標準創建可用于任何設備的應用程序。Silverlight 和 HTML 的互操作性還允許你通過混合應用程序進行逐步的過渡。

        移動

        Windows 8 商店有三個相等但是不同的選項

        就 Windows 8 商店應用而言，Microsoft 過去一直不愿意將開發人員推到某一種具體的技術棧上。這個政策現在也沒有發生變化；在 .NET/XAML、C++和 JavaScript/HTML5 這些技術之間選擇的首要標準是開發人員最熟悉哪種技術。

        除此之外，他們還提到了C++，因為它具有性能優勢。可重用性并不是很受關注的一個點，因為這三個平臺都能夠在 Windows Phone 和 Windows 桌面之間共享代碼和資源。

        本地選項適合 Windows Phone

        Windows Phone 推薦的技術是 .NET 和C++。再次重申，需要注意一下 C++ 的性能優勢，但是他們說的最多的還是開發者應該使用自己更加熟悉的技術。

        盡管 Windows Phone 兼容 PhoneGap/Apache Cordova，但是這并沒有被提及。推測起來原因可能是他們認為在小設備上 PhoneGap 的性能比起 .NET 或者 C++ 要差。在 2013 年度的 Build 大會上性能無疑是最重要的話題，超出了諸如一般可用性、可視化設計和深度 OS 集成等其他話題。

        移動 Web：都可以使用，除了 Web 表單

        如果你想選擇一種能夠在所有移動設備上運行的、基于 Web 的解決方案，那么有多種選擇。使用 Modernizer 的 ASP.NET MVC 是基線推薦方案，你能夠使用它創建單頁面應用程序（ASP.NET SPA）。Microsoft 對 SPA 的看法是它更像是一種設計模式而不是技術，同時 Microsoft 還極力推薦使用 Knockout 和 Breeze 這兩個類庫。

        為了快速地裝配 CRUD 風格的應用程序，LightSwitch 被列了出來。雖然該框架幾乎沒有對 HTML 渲染進行控制，但是卻可以讓開發人員不必為各種各樣的屏幕大小構建布局，減少了工作量。

        ASP.NET Web 頁面是為移動 Web 提供的第四個選項。它基于 Razor 語法，為開發者提供了與 PHP 和傳統 ASP 等腳本語言相似的開發體驗。

        指南中并沒有提及比較老的 ASP.NET 渲染工具箱——Web 表單。雖然該技術依然在積極的開發中，同時從理論上說它也能夠渲染設備特定的 HTML，但是在實踐中 Web 表單并沒有發揮其真正的潛力。它所渲染的 HTML 和 JavaScript 好像比較低效，此外其高級功能所必須的 view state 能快速地壓垮一個手機的網絡連接。

        服務

        因為大部分應用程序都依賴于外部的數據存儲和處理，所以服務器端開發依然是一個非常重要的考慮因素。Microsoft 認為現在有 6 種可行的技術選項。

        首選：ASP.NET Web API

        根據 Microsoft 所提供的信息，新項目的默認選擇應該是 ASP.NET Web API。如果要開發遵循 REST 風格的服務，或者需要兼容“Akamai、Windows Azure CDN、Level3 等”Internet 緩存，那么可以使用該技術。

        開發者在使用 Web API 的時候應該關注 OData 和 JSON，前者標準化了 REST 端點的暴露方式。

        第二選擇：WCF

        與 Web API 相比 WCF 被認為是一種更加靈活的選項，因為它并沒有與任何特定的傳輸協議或者消息格式綁定。例如，你能夠利用 TCP 或者命名管道和二進制消息提升性能。缺點是 WCF 使用起來比較困難，特別是當你想要以 JSON 或者其他非基于 SOAP 的格式暴露數據時更是如此。

        WCF 是面向企業設計的，理念是 RPC 風格的通信。雖然它也可以使用面向大眾的 REST 風格的設計模式，但是這并不是該場景下的首選項。

        WCF 和 OData

        如果你的主要工作是 CRUD 風格的服務層，同時想要使用 WCF 技術棧，那么 WCF 數據服務是一個不錯的選擇。它與 ASP.NET Web API 共享 OData 類庫，并且通常會與 Entity Framework 結合使用。

        Workflow 服務

        Workflow 服務是 Windows Workflow 與 WCF 的結合。使用它的原因只有一個，那就是你的服務內部已經使用了 Windows Workflow。Microsoft 認為沒有讓你選擇這個選項的其他原因。

        使用 SignalR 進行雙向通信

        如果你僅想使用基于 .NET 的客戶端，那么 WCF 為良好的雙向通信提供了很多選項。但是如果你想要的是能夠同時支持 .NET 和基于 Web 的客戶端，那么 SignalR 是一個非常不錯的選擇。

        根據 Microsoft 提供的信息，SignalR 甚至能夠擴展到上百萬用戶。Web 客戶端喜歡使用 WebSockets，但是可以在必要的時候自動地回退到舊的模式，例如長輪詢。

        SignalR 還有一個針對 .NET 客戶端的類庫，允許 Web 和本地客戶端共享服務。

        LightSwitch，另一個 OData 提供者

        Microsoft 對 OData 的喜愛程度夸張到我們幾乎難以用語言來描述。到現在為止，我們已經看到了用于 WCF 和 Web API 的 OData，但是這并沒有結束。盡管通常情況下我們使用的是 LightSwitch 的客戶端，但是很顯然我們還可以使用它的服務器端能力快速地生成一個服務層。

        Microsoft 宣稱 LightSwitch 不需要任何編碼，但是同時也警告說這樣會喪失靈活性。

        中小型企業應用程序指南

        Microsoft 為中小型企業編寫指南時一直遵循如下目標：

• 提高完成速度，縮短上市時間
• 提高生產效率并降低成本
• 容易開始
• 與市場產品的協作和集成
• 云計算的靈活性以及降低成本的機會

        通俗點說，它的意思就是“讓事情變得更快，成本更低”。Microsoft 提供的這個具體的指南取決于你喜歡什么樣的展示模式。

        中小型企業 Web 應用程序

        對于快速而隨意的 CRUD 風格的應用程序而言，Microsoft 推薦的首選平臺依然是 LightSwitch。LightSwitch 最初被描述為一個針對非專業程序員的工具。許多人將它看作是一個訪問的多層替代。但是隨著現在 Microsoft 更多的將其作為一個服務于需要快速推出應用程序的 IT 部門的工具，這個愿景似乎也已經消失。

        接下來要講的是 Web 表單。是的，令人尊敬的 Web 表單依然是新項目推薦使用的技術。Microsoft 將其看作是一種折中技術，介于易用但是有限制的 LightSwitch 和復雜的 ASP.NET MVC 之間。Web 表單包含豐富的數據表格等功能，它依然能夠非常好的適用于企業內部的應用程序。

        此外還提到了 ASP.NET Web 頁面，但僅僅是簡單介紹了一下。如果你認為 Web 表單所提供的渲染能力依然無法滿足自己的需求，那么可以選擇 ASP.NET MVC。但是 Microsoft 針對其較長時間的學習曲線提出了警告。

        構建 Windows 桌面程序

        雖然所有基于 C++ 的 GUI 工具集（例如 MFC 和 ATL/WTL）都不在列表上，但是最初的 .NET UI 工具集 WinForms 以及 WPF 依然被認為是可行的選項。這兩者都支持現代的理念，例如數據綁定和 async/await，同時都能夠使用 WCF 或者 SignalR 進行雙向通信。

        在 WPF 和 WinForms 之間做出選擇之前需要考慮下面幾點因素：

        首先是難度。比起 WPF 來 WinForms 更容易理解，甚至對高級開發者也是如此。WinForms 使用非常簡單的數據綁定，同時更喜歡傳統的 MVC 或者 MVP 機制。而對于 WPF 而言，用戶在能夠正確地使用 MVVP 模式之前需要學習一個復雜的數據綁定框架。成功地使用 WPF 還需要了解資源字典、轉換器、ICommands 和 XAML 模版引擎方面的知識。

        另一方面，如果你還打算把 Windows Phone 或者 Windows 8 商店作為目標平臺，那么你需要學習如何使用 XAML。在這種情況下，從 WPF 入手會讓你更有可能在不同的平臺之間共享代碼。

        與常見的 WinForms 應用程序相比，WPF 靈活的渲染引擎渲染的外觀更漂亮。當然這也是有代價的，在同等條件下 WPF 應用程序通常比 WinForms 應用程序運行的慢。

        順便提一下 LightSwitch 桌面客戶端。好像它并不能提供任何可以在桌面客戶端中使用的東西，所以似乎沒有太多的理由選擇它。

        應該避免使用客戶端—服務器模式

        當 Microsoft 談到“客戶端—服務器”的時候，他們實際上指的是那些直接與數據庫通信的應用程序。盡管他們承認這依然是一個非常常見的模式，但是他們還是希望新項目使用 3 層設計，在客戶端和數據庫之間創建一個服務層。與直接訪問數據庫相比，這提供了更好的可伸縮性，同時還提供了一種可以繞開防火墻及其他障礙物的方式。另外 它允許將應用程序移植到數據庫驅動不可用的平臺上。

        "現代化" —放棄 Windows 桌面

        對于如何“現代化”桌面應用程序 Microsoft 提供了很多建議。下面的建議大部分是有關于做好將應用程序遷移到其他平臺上的準備的，但是即使你并沒有打算放棄 Windows 桌面，這些指導對你而言依然是有一定用處的。相關建議的摘要如下：

• 使用模型—視圖—視圖模型（MVVM）設計模式：Microsoft 客戶端平臺（包括 WPF）讓我們能夠容易地使用 MVVM 模式構建應用程序。借助于該模式，你能夠將展現與狀態和行為分離，能夠創建可以容易地在不同設備間分享、干凈可維護的代碼。
• 客戶端邏輯使用可移植類庫：.NET 可移植類庫允許我們在多個平臺之間共享二進制，例如桌面、Windows 商店應用、Windows Phone 應用以及其他平臺。使用 .NET 可移植類庫實現客戶端邏輯能夠極大地簡化多個平臺上多種體驗的創建工作。
• 改進用戶體驗：最終用戶當前所需要的理念可以使用 .NET 針對桌面平臺最新的創新來實現。像“快速流暢”、“返璞歸真”和“事半功倍”這樣的設計原則能夠通過在 XAML 設計中使用現代 UI、謹慎地使用動畫以及廣泛地實現 .NET 異步編程這些方法應用到已有的桌面應用程序中。
• 將業務邏輯移動到服務器：雙層應用程序（客戶端/服務器）很難擴展到新設備上。推薦方式是將業務邏輯分離成非常清晰的服務，然后在其他設備上重用這些服務。
• 擴展到云端：一旦將業務邏輯從客戶端中分離出來，那么就可以借助于 Windows Azure 所提供的多種解決方案將其移動到云端。將這些邏輯改造成云服務能夠極大地提升已有解決方案的彈性和可擴展性，讓它們做好擁抱多種設備的準備。

        Android 和 iOS 平臺上的 .NET

        Microsoft 正在和一些合作伙伴一起努力，以幫助用戶實現現代化。下面是針對每一個合作伙伴所必須說的內容：

• Xamarin 是一個跨平臺的開發工具，以 Windows、Windows Phone、iOS 和 Android 設備為目標的應用程序能夠借助于它分享 C# 代碼。我們能夠使用它訪問底層 API，在設備間重用客戶端邏輯代碼的同時創建定制的視圖。
• ITR-Mobility iFactr 和 MonoCross 提供了一個解決方案，該方案允許我們使用 C# 構建可運行于主要移動平臺上的企業移動應用。它提供的抽象 UI 和企業數據同步等服務能夠讓業務程序跨多種設備。
• Mobilize.NET 來自于 Art in Soft 公司，它提供了可以幫助用戶將遺留應用程序遷移到現代化平臺（包括 Web、移動和云）上的解決方案和服務。方法是將已有的源碼轉換成沒有運行時的新代碼。
• Citrix Mobile SDK for Windows Applications 為開發人員提供了豐富的工具箱，能夠幫助他們移動化 LOB Windows 應用或者編寫新的能夠在中央服務器（Citrix XenApp/XenDesktop）上執行且能夠使用 Citrix Receiver 從任意移動設備訪問的觸摸友好的應用。

        邊注：Microsoft 正在積極推動 Xamarin 和 MonoCross 的事實最終應該會平息一直流傳的 Microsoft 打算控告 Mono 制造商的謠言。

        大型、關鍵業務應用程序指南

        對于大型企業以及它們的關鍵業務應用程序而言，焦點不再是成本和生產率，而是復雜性管理和服務的質量。下面的指導方針并不適合數據驅動或者 CRUD 風格的應用程序，從事這種工作的開發者應該參照中小型企業指南。這些指導方針適用于有許多相互聯系的部分同時有大量獨立子系統的系統。

        企業 Web 應用程序

        Microsoft 對于這一點的態度是明確的，他們認為關鍵的 Web 網站應該使用 ASP.NET MVC。唯一的架構問題是是否應該在它上面使用單頁面應用程序設計模式。

        不推薦使用其他 Web 技術，例如 Web 表單和 Web 頁面。因為它們不具備 MVC 的控制性和可測試性，這反過來限制了可獲得的服務的質量。

        企業桌面應用程序

        對于小型應用程序，Microsoft 的推薦列表中依然包含 WPF 和 WinForms。這種場景下他們還增加了 C++ 和 Win32/MFC。Microsoft 推薦在可以與 Microsoft Office 相比的這種大型、長期項目中使用C++。這里的一個假定是 AutoCAD 和 Paint.NET 在規模方面是不同的。

        企業 Windows 商店/Windows Phone

        對于這一場景，Microsoft 給出的建議類似于“新興應用程序模式”部分所給出的建議，除此之外并沒有其他內容。這樣的態度并沒有給用戶灌輸太多的信心，但是也沒有徹底地放棄平臺。

        模式和實踐

        在指南的最后，Microsoft 并沒有繼續討論產品，而是花了大約 20 頁左右的篇幅討論模式和實踐。

        控制反轉

        Microsoft 在討論依賴注入和控制反轉容器上花費的大量時間簡直令人驚訝。他們列出了 9 個單獨的控制反轉容器，其中最主要的一個是非附屬于 Microsoft 的社區運行的項目。應該注意的是，他們列出的許多框架并不是真正意義上的 IoC 容器，而是依賴注入框架。

        Microsoft 并沒有在這一部分清晰地表述出自己更喜歡組合根（一種 DI 模式）還是更喜歡服務定位（一種 IoC 容器模式），所以用戶對這兩者的疑惑依然存在，這相當令人沮喪，因為正如 Mark Seemann 所說：他們在本質上是對立的。

        Microsoft 使用了“單一職責模式”證明依賴注入的使用。例如，他們說 SRP 可能會導致一個類的構造函數中有 15 個依賴。為了“解耦”這些依賴，他們建議從構造函數中移除這些依賴，然后使用控制反轉容器進行注入。

        Microsoft 還提到應使用面向切面的編程添加一些其他的間接層，并且進一步注入依賴。

        邊界上下文和復雜性管理

        為了控制復雜性，Microsoft 花了幾頁討論“邊界上下文”的概念。據 Eric Evans 所說，它的基本思想是將應用程序分成更小的部分，各部分之間使用有限的共享。下面的例子有 4 個獨立的棧，它們使用不同的后端和一個共同的 UI。

        Microsoft 在這一部分的建議非常有道理。對于被識別出來作為關鍵任務的邊界上下文，你可以使用更加昂貴的命令、查詢職責分離（CQRS）或者領域驅動設計（DDD） 模式以及完全的自動化測試。同時，輔助性的邊界上下文可以使用輕量級的、CRUD 風格的架構。當然，遺留代碼會有它自己的倉庫，在那里它們會被隔離并被慢慢替代。

        通信和防護

        如果想要在邊界上下文之間共享信息，那么 Microsoft 推薦盡可能地使用異步消息。這樣每個部分就能夠獨立工作，即使某個部分失敗了也不會影響其他部分。對于簡單的場景，命名管道和 Microsoft 消息隊列是比較容易的選項，而更復雜的系統則需要一個服務總線。Microsoft 提到了 Windows Server 服務總線、Windows Azure 服務總線以及 NServiceBus，但是并沒有說更喜歡哪一個。

        邊界上下文暴露的所有服務都應該有一個防護層對其進行保護。就像應該對參數進行檢查以保護公共函數一樣，邊界上下文的防護層可以讓底層的數據存 儲免受畸形消息的侵害。這一層會驗證進入的消息，執行所有必要的轉換，并且確保壞數據會被處理和存儲。用戶可以使用普通的 .NET 代碼實現，但是對于復雜的、有很多頻繁變化的業務規則的場景，Microsoft 推薦使用規則引擎和集成平臺，例如 BizTalk。

        處理遺留代碼

        處理遺留代碼的第一步是為其創建一個外觀層。該外觀層應該使用現代的技術，例如持續的、可擴展的緩存，并且應該隱藏舊代碼使用的所有模式。隨著時間的推移，遺留代碼將會被置換，外觀層會被重定向到新的服務層。

        結論

        Microsoft 推薦使用所有的 .NET 本地、Web 和通信框架，瀏覽器端的 Silverlight 和 .NET Remoting 除外。在一些場景下他們還推薦使用 C++ 和 JavaScript。像 VB 6 和傳統 ASP 這樣的舊平臺根本沒有被提及，所以依然在使用這些技術的公司應該盡快地遷移到新技術上。

        不出所料，Microsoft 繼續強調了依賴注入，特別是它們與 ASP.NET MVC 及 Entity Framework 的結合。企業試圖集成現場和云架構的趨勢讓 BizTalk 這個一度被認為已經死亡的技術看到了再度煥發生機的希望。

        關于作者

        Jonathan Allen 從 2006 年開始就一直在為 InfoQ 撰寫新聞，他現在是 .NET 專欄的責任編輯。如果你想為 InfoQ 撰寫新聞或者教育性的文章，可以聯系他：jonathan@infoq.com。

                    <span id="shareA4" class="fl">                          </span>