這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)如何使用Microsoft技術(shù)棧，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

“只有客戶發(fā)展了，才有我們的生存與發(fā)展！”這是創(chuàng)新互聯(lián)的服務(wù)宗旨！把網(wǎng)站當(dāng)作互聯(lián)網(wǎng)產(chǎn)品，產(chǎn)品思維更注重全局思維、需求分析和迭代思維，在網(wǎng)站建設(shè)中就是為了建設(shè)一個(gè)不僅審美在線，而且實(shí)用性極高的網(wǎng)站。創(chuàng)新互聯(lián)對(duì)成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、網(wǎng)站開發(fā)、網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站優(yōu)化、網(wǎng)絡(luò)推廣、探索永無(wú)止境。

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

下面這個(gè)概要圖是我們探索Microsoft及其相關(guān)技術(shù)的一個(gè)很好的起點(diǎn)。

盡量早日放棄Silverlight和Flash

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

高端應(yīng)用程序更傾向于完全使用本地技術(shù)；而低端應(yīng)用程序則期望HTML5的能力持續(xù)發(fā)展。盡管沒(méi)有將開發(fā)人員推向具體的某一種技術(shù)，但是對(duì)于這種轉(zhuǎn)變我們必須要注意的事情是：

• 如果你正在過(guò)渡到本地應(yīng)用，那么你可以以生來(lái)就可以在任何Windows設(shè)備上運(yùn)行的XAML/.NET作為目標(biāo)，這樣你就能夠利用自己已有的技能甚至是代碼了?？梢浦差悗?kù)還允許你在不同的平臺(tái)之間共享類庫(kù)，包括Silverlight。

• 對(duì)于基于瀏覽器的HTML5應(yīng)用而言，Microsoft提供了主要的工具和框架，它們能夠幫助你基于最新的標(biāo)準(zhǔn)創(chuàng)建可用于任何設(shè)備的應(yīng)用程序。Silverlight和HTML的互操作性還允許你通過(guò)混合應(yīng)用程序進(jìn)行逐步的過(guò)渡。

移動(dòng)

Windows 8商店有三個(gè)相等但是不同的選項(xiàng)

就Windows 8商店應(yīng)用而言，Microsoft過(guò)去一直不愿意將開發(fā)人員推到某一種具體的技術(shù)棧上。這個(gè)政策現(xiàn)在也沒(méi)有發(fā)生變化；在.NET/XAML、C++和JavaScript/HTML5這些技術(shù)之間選擇的首要標(biāo)準(zhǔn)是開發(fā)人員最熟悉哪種技術(shù)。

除此之外，他們還提到了C++，因?yàn)樗哂行阅軆?yōu)勢(shì)。可重用性并不是很受關(guān)注的一個(gè)點(diǎn)，因?yàn)檫@三個(gè)平臺(tái)都能夠在Windows Phone和Windows桌面之間共享代碼和資源。

本地選項(xiàng)適合Windows Phone

Windows Phone推薦的技術(shù)是.NET和C++。再次重申，需要注意一下C++的性能優(yōu)勢(shì)，但是他們說(shuō)的最多的還是開發(fā)者應(yīng)該使用自己更加熟悉的技術(shù)。

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

移動(dòng)Web：都可以使用，除了Web表單

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

為了快速地裝配CRUD風(fēng)格的應(yīng)用程序，LightSwitch被列了出來(lái)。雖然該框架幾乎沒(méi)有對(duì)HTML渲染進(jìn)行控制，但是卻可以讓開發(fā)人員不必為各種各樣的屏幕大小構(gòu)建布局，減少了工作量。

ASP.NET Web頁(yè)面是為移動(dòng)Web提供的第四個(gè)選項(xiàng)。它基于Razor語(yǔ)法，為開發(fā)者提供了與PHP和傳統(tǒng)ASP等腳本語(yǔ)言相似的開發(fā)體驗(yàn)。

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

服務(wù)

因?yàn)榇蟛糠謶?yīng)用程序都依賴于外部的數(shù)據(jù)存儲(chǔ)和處理，所以服務(wù)器端開發(fā)依然是一個(gè)非常重要的考慮因素。Microsoft認(rèn)為現(xiàn)在有6種可行的技術(shù)選項(xiàng)。

首選：ASP.NET Web API

根據(jù)Microsoft所提供的信息，新項(xiàng)目的默認(rèn)選擇應(yīng)該是ASP.NET Web API。如果要開發(fā)遵循REST風(fēng)格的服務(wù)，或者需要兼容“Akamai、Windows Azure cdn、Level3等”Internet緩存，那么可以使用該技術(shù)。

開發(fā)者在使用Web API的時(shí)候應(yīng)該關(guān)注OData和JSON，前者標(biāo)準(zhǔn)化了REST端點(diǎn)的暴露方式。

第二選擇：WCF

與Web API相比WCF被認(rèn)為是一種更加靈活的選項(xiàng)，因?yàn)樗](méi)有與任何特定的傳輸協(xié)議或者消息格式綁定。例如，你能夠利用TCP或者命名管道和二進(jìn)制消息提升性能。缺點(diǎn)是WCF使用起來(lái)比較困難，特別是當(dāng)你想要以JSON或者其他非基于SOAP的格式暴露數(shù)據(jù)時(shí)更是如此。

WCF是面向企業(yè)設(shè)計(jì)的，理念是RPC風(fēng)格的通信。雖然它也可以使用面向大眾的REST風(fēng)格的設(shè)計(jì)模式，但是這并不是該場(chǎng)景下的首選項(xiàng)。

WCF和OData

如果你的主要工作是CRUD風(fēng)格的服務(wù)層，同時(shí)想要使用WCF技術(shù)棧，那么WCF數(shù)據(jù)服務(wù)是一個(gè)不錯(cuò)的選擇。它與ASP.NET Web API共享OData類庫(kù)，并且通常會(huì)與Entity Framework結(jié)合使用。

Workflow服務(wù)

Workflow服務(wù)是Windows Workflow與WCF的結(jié)合。使用它的原因只有一個(gè)，那就是你的服務(wù)內(nèi)部已經(jīng)使用了Windows Workflow。Microsoft認(rèn)為沒(méi)有讓你選擇這個(gè)選項(xiàng)的其他原因。

使用SignalR進(jìn)行雙向通信

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

根據(jù)Microsoft提供的信息，SignalR甚至能夠擴(kuò)展到上百萬(wàn)用戶。Web客戶端喜歡使用WebSockets，但是可以在必要的時(shí)候自動(dòng)地回退到舊的模式，例如長(zhǎng)輪詢。

SignalR還有一個(gè)針對(duì).NET客戶端的類庫(kù)，允許Web和本地客戶端共享服務(wù)。

LightSwitch，另一個(gè)OData提供者

Microsoft對(duì)OData的喜愛(ài)程度夸張到我們幾乎難以用語(yǔ)言來(lái)描述。到現(xiàn)在為止，我們已經(jīng)看到了用于WCF和Web API的OData，但是這并沒(méi)有結(jié)束。盡管通常情況下我們使用的是LightSwitch的客戶端，但是很顯然我們還可以使用它的服務(wù)器端能力快速地生成一個(gè)服務(wù)層。

Microsoft宣稱LightSwitch不需要任何編碼，但是同時(shí)也警告說(shuō)這樣會(huì)喪失靈活性。

中小型企業(yè)應(yīng)用程序指南

Microsoft為中小型企業(yè)編寫指南時(shí)一直遵循如下目標(biāo)：

• 提高完成速度，縮短上市時(shí)間

• 提高生產(chǎn)效率并降低成本

• 容易開始

• 與市場(chǎng)產(chǎn)品的協(xié)作和集成

• 云計(jì)算的靈活性以及降低成本的機(jī)會(huì)

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

中小型企業(yè)Web應(yīng)用程序

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

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

此外還提到了ASP.NET Web頁(yè)面，但僅僅是簡(jiǎn)單介紹了一下。如果你認(rèn)為Web表單所提供的渲染能力依然無(wú)法滿足自己的需求，那么可以選擇ASP.NET MVC。但是Microsoft針對(duì)其較長(zhǎng)時(shí)間的學(xué)習(xí)曲線提出了警告。

構(gòu)建Windows桌面程序

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

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

首先是難度。比起WPF來(lái)WinForms更容易理解，甚至對(duì)高級(jí)開發(fā)者也是如此。WinForms使用非常簡(jiǎn)單的數(shù)據(jù)綁定，同時(shí)更喜歡傳統(tǒng)的MVC或者M(jìn)VP機(jī)制。而對(duì)于WPF而言，用戶在能夠正確地使用MVVP模式之前需要學(xué)習(xí)一個(gè)復(fù)雜的數(shù)據(jù)綁定框架。成功地使用WPF還需要了解資源字典、轉(zhuǎn)換器、ICommands和XAML模版引擎方面的知識(shí)。

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

與常見的WinForms應(yīng)用程序相比，WPF靈活的渲染引擎渲染的外觀更漂亮。當(dāng)然這也是有代價(jià)的，在同等條件下WPF應(yīng)用程序通常比WinForms應(yīng)用程序運(yùn)行的慢。

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

應(yīng)該避免使用客戶端—服務(wù)器模式

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

"現(xiàn)代化" —放棄Windows桌面

對(duì)于如何“現(xiàn)代化”桌面應(yīng)用程序Microsoft提供了很多建議。下面的建議大部分是有關(guān)于做好將應(yīng)用程序遷移到其他平臺(tái)上的準(zhǔn)備的，但是即使你并沒(méi)有打算放棄Windows桌面，這些指導(dǎo)對(duì)你而言依然是有一定用處的。相關(guān)建議的摘要如下：

• 使用模型—視圖—視圖模型（MVVM）設(shè)計(jì)模式：Microsoft客戶端平臺(tái)（包括WPF）讓我們能夠容易地使用MVVM模式構(gòu)建應(yīng)用程序。借助于該模式，你能夠?qū)⒄宫F(xiàn)與狀態(tài)和行為分離，能夠創(chuàng)建可以容易地在不同設(shè)備間分享、干凈可維護(hù)的代碼。

• 客戶端邏輯使用可移植類庫(kù)：.NET可移植類庫(kù)允許我們?cè)诙鄠€(gè)平臺(tái)之間共享二進(jìn)制，例如桌面、Windows商店應(yīng)用、Windows Phone應(yīng)用以及其他平臺(tái)。使用.NET可移植類庫(kù)實(shí)現(xiàn)客戶端邏輯能夠極大地簡(jiǎn)化多個(gè)平臺(tái)上多種體驗(yàn)的創(chuàng)建工作。

• 改進(jìn)用戶體驗(yàn)：最終用戶當(dāng)前所需要的理念可以使用.NET針對(duì)桌面平臺(tái)最新的創(chuàng)新來(lái)實(shí)現(xiàn)。像“快速流暢”、“返璞歸真”和“事半功倍”這樣的設(shè)計(jì)原則能夠通過(guò)在XAML設(shè)計(jì)中使用現(xiàn)代UI、謹(jǐn)慎地使用動(dòng)畫以及廣泛地實(shí)現(xiàn).NET異步編程這些方法應(yīng)用到已有的桌面應(yīng)用程序中。

• 將業(yè)務(wù)邏輯移動(dòng)到服務(wù)器：雙層應(yīng)用程序（客戶端/服務(wù)器）很難擴(kuò)展到新設(shè)備上。推薦方式是將業(yè)務(wù)邏輯分離成非常清晰的服務(wù)，然后在其他設(shè)備上重用這些服務(wù)。

• 擴(kuò)展到云端：一旦將業(yè)務(wù)邏輯從客戶端中分離出來(lái)，那么就可以借助于Windows Azure所提供的多種解決方案將其移動(dòng)到云端。將這些邏輯改造成云服務(wù)能夠極大地提升已有解決方案的彈性和可擴(kuò)展性，讓它們做好擁抱多種設(shè)備的準(zhǔn)備。

Android和iOS平臺(tái)上的.NET

Microsoft正在和一些合作伙伴一起努力，以幫助用戶實(shí)現(xiàn)現(xiàn)代化。下面是針對(duì)每一個(gè)合作伙伴所必須說(shuō)的內(nèi)容：

• Xamarin 是一個(gè)跨平臺(tái)的開發(fā)工具，以Windows、Windows Phone、iOS和Android設(shè)備為目標(biāo)的應(yīng)用程序能夠借助于它分享C#代碼。我們能夠使用它訪問(wèn)底層API，在設(shè)備間重用客戶端邏輯代碼的同時(shí)創(chuàng)建定制的視圖。

• ITR-Mobility iFactr 和MonoCross 提供了一個(gè)解決方案，該方案允許我們使用C#構(gòu)建可運(yùn)行于主要移動(dòng)平臺(tái)上的企業(yè)移動(dòng)應(yīng)用。它提供的抽象UI和企業(yè)數(shù)據(jù)同步等服務(wù)能夠讓業(yè)務(wù)程序跨多種設(shè)備。

• Mobilize.NET來(lái)自于Art in Soft公司，它提供了可以幫助用戶將遺留應(yīng)用程序遷移到現(xiàn)代化平臺(tái)（包括Web、移動(dòng)和云）上的解決方案和服務(wù)。方法是將已有的源碼轉(zhuǎn)換成沒(méi)有運(yùn)行時(shí)的新代碼。

• Citrix Mobile SDK for Windows Applications為開發(fā)人員提供了豐富的工具箱，能夠幫助他們移動(dòng)化LOB Windows應(yīng)用或者編寫新的能夠在中央服務(wù)器（Citrix XenApp/XenDesktop）上執(zhí)行且能夠使用Citrix Receiver從任意移動(dòng)設(shè)備訪問(wèn)的觸摸友好的應(yīng)用。

邊注：Microsoft正在積極推動(dòng)Xamarin和MonoCross的事實(shí)最終應(yīng)該會(huì)平息一直流傳的Microsoft打算控告Mono制造商的謠言。

大型、關(guān)鍵業(yè)務(wù)應(yīng)用程序指南

對(duì)于大型企業(yè)以及它們的關(guān)鍵業(yè)務(wù)應(yīng)用程序而言，焦點(diǎn)不再是成本和生產(chǎn)率，而是復(fù)雜性管理和服務(wù)的質(zhì)量。下面的指導(dǎo)方針并不適合數(shù)據(jù)驅(qū)動(dòng)或者CRUD風(fēng)格的應(yīng)用程序，從事這種工作的開發(fā)者應(yīng)該參照中小型企業(yè)指南。這些指導(dǎo)方針適用于有許多相互聯(lián)系的部分同時(shí)有大量獨(dú)立子系統(tǒng)的系統(tǒng)。

企業(yè)Web應(yīng)用程序

Microsoft對(duì)于這一點(diǎn)的態(tài)度是明確的，他們認(rèn)為關(guān)鍵的Web網(wǎng)站應(yīng)該使用ASP.NET MVC。唯一的架構(gòu)問(wèn)題是是否應(yīng)該在它上面使用單頁(yè)面應(yīng)用程序設(shè)計(jì)模式。

不推薦使用其他Web技術(shù)，例如Web表單和Web頁(yè)面。因?yàn)樗鼈儾痪邆銶VC的控制性和可測(cè)試性，這反過(guò)來(lái)限制了可獲得的服務(wù)的質(zhì)量。

企業(yè)桌面應(yīng)用程序

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

企業(yè)Windows商店/Windows Phone

對(duì)于這一場(chǎng)景，Microsoft給出的建議類似于“新興應(yīng)用程序模式”部分所給出的建議，除此之外并沒(méi)有其他內(nèi)容。這樣的態(tài)度并沒(méi)有給用戶灌輸太多的信心，但是也沒(méi)有徹底地放棄平臺(tái)。

模式和實(shí)踐

在指南的最后，Microsoft并沒(méi)有繼續(xù)討論產(chǎn)品，而是花了大約20頁(yè)左右的篇幅討論模式和實(shí)踐。

控制反轉(zhuǎn)

Microsoft在討論依賴注入和控制反轉(zhuǎn)容器上花費(fèi)的大量時(shí)間簡(jiǎn)直令人驚訝。他們列出了9個(gè)單獨(dú)的控制反轉(zhuǎn)容器，其中最主要的一個(gè)是非附屬于Microsoft的社區(qū)運(yùn)行的項(xiàng)目。應(yīng)該注意的是，他們列出的許多框架并不是真正意義上的IoC容器，而是依賴注入框架。

Microsoft并沒(méi)有在這一部分清晰地表述出自己更喜歡組合根（一種DI模式）還是更喜歡服務(wù)定位（一種IoC容器模式），所以用戶對(duì)這兩者的疑惑依然存在，這相當(dāng)令人沮喪，因?yàn)檎鏜ark Seemann所說(shuō)：他們?cè)诒举|(zhì)上是對(duì)立的。

Microsoft使用了“單一職責(zé)模式”證明依賴注入的使用。例如，他們說(shuō)SRP可能會(huì)導(dǎo)致一個(gè)類的構(gòu)造函數(shù)中有15個(gè)依賴。為了“解耦”這些依賴，他們建議從構(gòu)造函數(shù)中移除這些依賴，然后使用控制反轉(zhuǎn)容器進(jìn)行注入。

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

邊界上下文和復(fù)雜性管理

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

Microsoft在這一部分的建議非常有道理。對(duì)于被識(shí)別出來(lái)作為關(guān)鍵任務(wù)的邊界上下文，你可以使用更加昂貴的命令、查詢職責(zé)分離（CQRS）或者領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）模式以及完全的自動(dòng)化測(cè)試。同時(shí)，輔助性的邊界上下文可以使用輕量級(jí)的、CRUD風(fēng)格的架構(gòu)。當(dāng)然，遺留代碼會(huì)有它自己的倉(cāng)庫(kù)，在那里它們會(huì)被隔離并被慢慢替代。

通信和防護(hù)

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

邊界上下文暴露的所有服務(wù)都應(yīng)該有一個(gè)防護(hù)層對(duì)其進(jìn)行保護(hù)。就像應(yīng)該對(duì)參數(shù)進(jìn)行檢查以保護(hù)公共函數(shù)一樣，邊界上下文的防護(hù)層可以讓底層的數(shù)據(jù)存儲(chǔ)免受畸形消息的侵害。這一層會(huì)驗(yàn)證進(jìn)入的消息，執(zhí)行所有必要的轉(zhuǎn)換，并且確保壞數(shù)據(jù)會(huì)被處理和存儲(chǔ)。用戶可以使用普通的.NET代碼實(shí)現(xiàn)，但是對(duì)于復(fù)雜的、有很多頻繁變化的業(yè)務(wù)規(guī)則的場(chǎng)景，Microsoft推薦使用規(guī)則引擎和集成平臺(tái)，例如BizTalk。

處理遺留代碼

處理遺留代碼的第一步是為其創(chuàng)建一個(gè)外觀層。該外觀層應(yīng)該使用現(xiàn)代的技術(shù)，例如持續(xù)的、可擴(kuò)展的緩存，并且應(yīng)該隱藏舊代碼使用的所有模式。隨著時(shí)間的推移，遺留代碼將會(huì)被置換，外觀層會(huì)被重定向到新的服務(wù)層。

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

不出所料，Microsoft繼續(xù)強(qiáng)調(diào)了依賴注入，特別是它們與ASP.NET MVC及Entity Framework的結(jié)合。企業(yè)試圖集成現(xiàn)場(chǎng)和云架構(gòu)的趨勢(shì)讓BizTalk這個(gè)一度被認(rèn)為已經(jīng)死亡的技術(shù)看到了再度煥發(fā)生機(jī)的希望。

上述就是小編為大家分享的如何使用Microsoft技術(shù)棧了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

文章題目：如何使用Microsoft技術(shù)棧
文章地址：http://chinadenli.net/article28/ihgcjp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、微信公眾號(hào)、網(wǎng)站設(shè)計(jì)、移動(dòng)網(wǎng)站建設(shè)、面包屑導(dǎo)航、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)