如何使用Microsoft技術棧

　　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。

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