如何使用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這個一度被認爲已經死亡的技術看到了再度煥發生機的但願