發(fā)文章
發(fā)文工具
撰寫
網(wǎng)文摘手
文檔
視頻
思維導(dǎo)圖
隨筆
相冊
原創(chuàng)同步助手
其他工具
圖片轉(zhuǎn)文字
文件清理
AI助手
留言交流
Microsoft技術(shù)棧最近有大量的變遷，這使得開發(fā)人員和領(lǐng)導(dǎo)者都想知道他們到底應(yīng)該關(guān)注哪些技術(shù)。Microsoft自己并不想從官方層面上反對Silverlight這樣的技術(shù)，相對而言他們更喜歡讓這種技術(shù)慢慢淡出人們的視線，否則局面可能會更加混亂。如果你想了解該問題的答案，那么可以查看“.NET業(yè)務(wù)應(yīng)用程序技術(shù)指南”這個小有名氣的文檔。該文檔發(fā)布于去年早些時候，它深入探討了Microsoft打算在哪些領(lǐng)域付出努力，我們應(yīng)該回避哪些技術(shù)等內(nèi)容。
下面這個概要圖是我們探索Microsoft及其相關(guān)技術(shù)的一個很好的起點。
(單擊放大圖片)
雖然WinForms和Web表單這些舊的.NET技術(shù)依然占有一席之地，但是Silverlight和Flash這樣的RIA容器絕對是出局了。正如下面圖5-15所展示的，Microsoft并不想空等著Silverlight 5所計劃的10年生命周期。他們已經(jīng)打算在2015年底放棄RIA容器。
高端應(yīng)用程序更傾向于完全使用本地技術(shù)；而低端應(yīng)用程序則期望HTML5的能力持續(xù)發(fā)展。盡管沒有將開發(fā)人員推向具體的某一種技術(shù)，但是對于這種轉(zhuǎn)變我們必須要注意的事情是：
Windows 8商店有三個相等但是不同的選項
就Windows 8商店應(yīng)用而言，Microsoft過去一直不愿意將開發(fā)人員推到某一種具體的技術(shù)棧上。這個政策現(xiàn)在也沒有發(fā)生變化；在.NET/XAML、C++和JavaScript/HTML5這些技術(shù)之間選擇的首要標準是開發(fā)人員最熟悉哪種技術(shù)。
除此之外，他們還提到了C++，因為它具有性能優(yōu)勢?？芍赜眯圆⒉皇呛苁荜P(guān)注的一個點，因為這三個平臺都能夠在Windows Phone和Windows桌面之間共享代碼和資源。
Windows Phone推薦的技術(shù)是.NET和C++。再次重申，需要注意一下C++的性能優(yōu)勢，但是他們說的最多的還是開發(fā)者應(yīng)該使用自己更加熟悉的技術(shù)。
盡管Windows Phone兼容PhoneGap/Apache Cordova，但是這并沒有被提及。推測起來原因可能是他們認為在小設(shè)備上PhoneGap的性能比起.NET或者C++要差。在2013年度的Build大會上性能無疑是最重要的話題，超出了諸如一般可用性、可視化設(shè)計和深度OS集成等其他話題。
如果你想選擇一種能夠在所有移動設(shè)備上運行的、基于Web的解決方案，那么有多種選擇。使用Modernizer的ASP.NET MVC是基線推薦方案，你能夠使用它創(chuàng)建單頁面應(yīng)用程序（ASP.NET SPA）。Microsoft對SPA的看法是它更像是一種設(shè)計模式而不是技術(shù)，同時Microsoft還極力推薦使用Knockout和Breeze這兩個類庫。
為了快速地裝配CRUD風(fēng)格的應(yīng)用程序，LightSwitch被列了出來。雖然該框架幾乎沒有對HTML渲染進行控制，但是卻可以讓開發(fā)人員不必為各種各樣的屏幕大小構(gòu)建布局，減少了工作量。
ASP.NET Web頁面是為移動Web提供的第四個選項。它基于Razor語法，為開發(fā)者提供了與PHP和傳統(tǒng)ASP等腳本語言相似的開發(fā)體驗。
指南中并沒有提及比較老的ASP.NET渲染工具箱——Web表單。雖然該技術(shù)依然在積極的開發(fā)中，同時從理論上說它也能夠渲染設(shè)備特定的HTML，但是在實踐中Web表單并沒有發(fā)揮其真正的潛力。它所渲染的HTML和JavaScript好像比較低效，此外其高級功能所必須的view state能快速地壓垮一個手機的網(wǎng)絡(luò)連接。
因為大部分應(yīng)用程序都依賴于外部的數(shù)據(jù)存儲和處理，所以服務(wù)器端開發(fā)依然是一個非常重要的考慮因素。Microsoft認為現(xiàn)在有6種可行的技術(shù)選項。
根據(jù)Microsoft所提供的信息，新項目的默認選擇應(yīng)該是ASP.NET Web API。如果要開發(fā)遵循REST風(fēng)格的服務(wù)，或者需要兼容“Akamai、Windows Azure CDN、Level3等”Internet緩存，那么可以使用該技術(shù)。
開發(fā)者在使用Web API的時候應(yīng)該關(guān)注OData和JSON，前者標準化了REST端點的暴露方式。
與Web API相比WCF被認為是一種更加靈活的選項，因為它并沒有與任何特定的傳輸協(xié)議或者消息格式綁定。例如，你能夠利用TCP或者命名管道和二進制消息提升性能。缺點是WCF使用起來比較困難，特別是當你想要以JSON或者其他非基于SOAP的格式暴露數(shù)據(jù)時更是如此。
WCF是面向企業(yè)設(shè)計的，理念是RPC風(fēng)格的通信。雖然它也可以使用面向大眾的REST風(fēng)格的設(shè)計模式，但是這并不是該場景下的首選項。
如果你的主要工作是CRUD風(fēng)格的服務(wù)層，同時想要使用WCF技術(shù)棧，那么WCF數(shù)據(jù)服務(wù)是一個不錯的選擇。它與ASP.NET Web API共享OData類庫，并且通常會與Entity Framework結(jié)合使用。
Workflow服務(wù)是Windows Workflow與WCF的結(jié)合。使用它的原因只有一個，那就是你的服務(wù)內(nèi)部已經(jīng)使用了Windows Workflow。Microsoft認為沒有讓你選擇這個選項的其他原因。
如果你僅想使用基于.NET的客戶端，那么WCF為良好的雙向通信提供了很多選項。但是如果你想要的是能夠同時支持.NET和基于Web的客戶端，那么SignalR是一個非常不錯的選擇。
根據(jù)Microsoft提供的信息，SignalR甚至能夠擴展到上百萬用戶。Web客戶端喜歡使用WebSockets，但是可以在必要的時候自動地回退到舊的模式，例如長輪詢。
SignalR還有一個針對.NET客戶端的類庫，允許Web和本地客戶端共享服務(wù)。
Microsoft對OData的喜愛程度夸張到我們幾乎難以用語言來描述。到現(xiàn)在為止，我們已經(jīng)看到了用于WCF和Web API的OData，但是這并沒有結(jié)束。盡管通常情況下我們使用的是LightSwitch的客戶端，但是很顯然我們還可以使用它的服務(wù)器端能力快速地生成一個服務(wù)層。
Microsoft宣稱LightSwitch不需要任何編碼，但是同時也警告說這樣會喪失靈活性。
Microsoft為中小型企業(yè)編寫指南時一直遵循如下目標：
通俗點說，它的意思就是“讓事情變得更快，成本更低”。Microsoft提供的這個具體的指南取決于你喜歡什么樣的展示模式。
對于快速而隨意的CRUD風(fēng)格的應(yīng)用程序而言，Microsoft推薦的首選平臺依然是LightSwitch。LightSwitch最初被描述為一個針對非專業(yè)程序員的工具。許多人將它看作是一個訪問的多層替代。但是隨著現(xiàn)在Microsoft更多的將其作為一個服務(wù)于需要快速推出應(yīng)用程序的IT部門的工具，這個愿景似乎也已經(jīng)消失。
接下來要講的是Web表單。是的，令人尊敬的Web表單依然是新項目推薦使用的技術(shù)。Microsoft將其看作是一種折中技術(shù)，介于易用但是有限制的LightSwitch和復(fù)雜的ASP.NET MVC之間。Web表單包含豐富的數(shù)據(jù)表格等功能，它依然能夠非常好的適用于企業(yè)內(nèi)部的應(yīng)用程序。
此外還提到了ASP.NET Web頁面，但僅僅是簡單介紹了一下。如果你認為Web表單所提供的渲染能力依然無法滿足自己的需求，那么可以選擇ASP.NET MVC。但是Microsoft針對其較長時間的學(xué)習(xí)曲線提出了警告。
雖然所有基于C++的GUI工具集（例如MFC和ATL/WTL）都不在列表上，但是最初的.NET UI工具集WinForms以及WPF依然被認為是可行的選項。這兩者都支持現(xiàn)代的理念，例如數(shù)據(jù)綁定和async/await，同時都能夠使用WCF或者SignalR進行雙向通信。
在WPF和WinForms之間做出選擇之前需要考慮下面幾點因素：
首先是難度。比起WPF來WinForms更容易理解，甚至對高級開發(fā)者也是如此。WinForms使用非常簡單的數(shù)據(jù)綁定，同時更喜歡傳統(tǒng)的MVC或者MVP機制。而對于WPF而言，用戶在能夠正確地使用MVVP模式之前需要學(xué)習(xí)一個復(fù)雜的數(shù)據(jù)綁定框架。成功地使用WPF還需要了解資源字典、轉(zhuǎn)換器、ICommands和XAML模版引擎方面的知識。
另一方面，如果你還打算把Windows Phone或者Windows 8 商店作為目標平臺，那么你需要學(xué)習(xí)如何使用XAML。在這種情況下，從WPF入手會讓你更有可能在不同的平臺之間共享代碼。
與常見的WinForms應(yīng)用程序相比，WPF靈活的渲染引擎渲染的外觀更漂亮。當然這也是有代價的，在同等條件下WPF應(yīng)用程序通常比WinForms應(yīng)用程序運行的慢。
順便提一下LightSwitch桌面客戶端。好像它并不能提供任何可以在桌面客戶端中使用的東西，所以似乎沒有太多的理由選擇它。
當Microsoft談到“客戶端—服務(wù)器”的時候，他們實際上指的是那些直接與數(shù)據(jù)庫通信的應(yīng)用程序。盡管他們承認這依然是一個非常常見的模式，但是他們還是希望新項目使用3層設(shè)計，在客戶端和數(shù)據(jù)庫之間創(chuàng)建一個服務(wù)層。與直接訪問數(shù)據(jù)庫相比，這提供了更好的可伸縮性，同時還提供了一種可以繞開防火墻及其他障礙物的方式。另外它允許將應(yīng)用程序移植到數(shù)據(jù)庫驅(qū)動不可用的平臺上。
對于如何“現(xiàn)代化”桌面應(yīng)用程序Microsoft提供了很多建議。下面的建議大部分是有關(guān)于做好將應(yīng)用程序遷移到其他平臺上的準備的，但是即使你并沒有打算放棄Windows桌面，這些指導(dǎo)對你而言依然是有一定用處的。相關(guān)建議的摘要如下：
Microsoft正在和一些合作伙伴一起努力，以幫助用戶實現(xiàn)現(xiàn)代化。下面是針對每一個合作伙伴所必須說的內(nèi)容：
邊注：Microsoft正在積極推動Xamarin和MonoCross的事實最終應(yīng)該會平息一直流傳的Microsoft打算控告Mono制造商的謠言。
對于大型企業(yè)以及它們的關(guān)鍵業(yè)務(wù)應(yīng)用程序而言，焦點不再是成本和生產(chǎn)率，而是復(fù)雜性管理和服務(wù)的質(zhì)量。下面的指導(dǎo)方針并不適合數(shù)據(jù)驅(qū)動或者CRUD風(fēng)格的應(yīng)用程序，從事這種工作的開發(fā)者應(yīng)該參照中小型企業(yè)指南。這些指導(dǎo)方針適用于有許多相互聯(lián)系的部分同時有大量獨立子系統(tǒng)的系統(tǒng)。
Microsoft對于這一點的態(tài)度是明確的，他們認為關(guān)鍵的Web網(wǎng)站應(yīng)該使用ASP.NET MVC。唯一的架構(gòu)問題是是否應(yīng)該在它上面使用單頁面應(yīng)用程序設(shè)計模式。
不推薦使用其他Web技術(shù)，例如Web表單和Web頁面。因為它們不具備MVC的控制性和可測試性，這反過來限制了可獲得的服務(wù)的質(zhì)量。
對于小型應(yīng)用程序，Microsoft的推薦列表中依然包含WPF和WinForms。這種場景下他們還增加了C++和Win32/MFC。Microsoft推薦在可以與Microsoft Office相比的這種大型、長期項目中使用C++。這里的一個假定是AutoCAD和Paint.NET在規(guī)模方面是不同的。
對于這一場景，Microsoft給出的建議類似于“新興應(yīng)用程序模式”部分所給出的建議，除此之外并沒有其他內(nèi)容。這樣的態(tài)度并沒有給用戶灌輸太多的信心，但是也沒有徹底地放棄平臺。
在指南的最后，Microsoft并沒有繼續(xù)討論產(chǎn)品，而是花了大約20頁左右的篇幅討論模式和實踐。
Microsoft在討論依賴注入和控制反轉(zhuǎn)容器上花費的大量時間簡直令人驚訝。他們列出了9個單獨的控制反轉(zhuǎn)容器，其中最主要的一個是非附屬于Microsoft的社區(qū)運行的項目。應(yīng)該注意的是，他們列出的許多框架并不是真正意義上的IoC容器，而是依賴注入框架。
Microsoft并沒有在這一部分清晰地表述出自己更喜歡組合根（一種DI模式）還是更喜歡服務(wù)定位（一種IoC容器模式），所以用戶對這兩者的疑惑依然存在，這相當令人沮喪，因為正如Mark Seemann所說：他們在本質(zhì)上是對立的。
Microsoft使用了“單一職責(zé)模式”證明依賴注入的使用。例如，他們說SRP可能會導(dǎo)致一個類的構(gòu)造函數(shù)中有15個依賴。為了“解耦”這些依賴，他們建議從構(gòu)造函數(shù)中移除這些依賴，然后使用控制反轉(zhuǎn)容器進行注入。
Microsoft還提到應(yīng)使用面向切面的編程添加一些其他的間接層，并且進一步注入依賴。
為了控制復(fù)雜性，Microsoft花了幾頁討論“邊界上下文”的概念。據(jù)Eric Evans所說，它的基本思想是將應(yīng)用程序分成更小的部分，各部分之間使用有限的共享。下面的例子有4個獨立的棧，它們使用不同的后端和一個共同的UI。
（單擊放大圖片）
Microsoft在這一部分的建議非常有道理。對于被識別出來作為關(guān)鍵任務(wù)的邊界上下文，你可以使用更加昂貴的命令、查詢職責(zé)分離（CQRS）或者領(lǐng)域驅(qū)動設(shè)計（DDD）模式以及完全的自動化測試。同時，輔助性的邊界上下文可以使用輕量級的、CRUD風(fēng)格的架構(gòu)。當然，遺留代碼會有它自己的倉庫，在那里它們會被隔離并被慢慢替代。
如果想要在邊界上下文之間共享信息，那么Microsoft推薦盡可能地使用異步消息。這樣每個部分就能夠獨立工作，即使某個部分失敗了也不會影響其他部分。對于簡單的場景，命名管道和Microsoft消息隊列是比較容易的選項，而更復(fù)雜的系統(tǒng)則需要一個服務(wù)總線。Microsoft提到了Windows Server服務(wù)總線、Windows Azure服務(wù)總線以及NServiceBus，但是并沒有說更喜歡哪一個。
邊界上下文暴露的所有服務(wù)都應(yīng)該有一個防護層對其進行保護。就像應(yīng)該對參數(shù)進行檢查以保護公共函數(shù)一樣，邊界上下文的防護層可以讓底層的數(shù)據(jù)存儲免受畸形消息的侵害。這一層會驗證進入的消息，執(zhí)行所有必要的轉(zhuǎn)換，并且確保壞數(shù)據(jù)會被處理和存儲。用戶可以使用普通的.NET代碼實現(xiàn)，但是對于復(fù)雜的、有很多頻繁變化的業(yè)務(wù)規(guī)則的場景，Microsoft推薦使用規(guī)則引擎和集成平臺，例如BizTalk。
處理遺留代碼的第一步是為其創(chuàng)建一個外觀層。該外觀層應(yīng)該使用現(xiàn)代的技術(shù)，例如持續(xù)的、可擴展的緩存，并且應(yīng)該隱藏舊代碼使用的所有模式。隨著時間的推移，遺留代碼將會被置換，外觀層會被重定向到新的服務(wù)層。
Microsoft推薦使用所有的.NET 本地、Web和通信框架，瀏覽器端的Silverlight和.NET Remoting除外。在一些場景下他們還推薦使用C++和JavaScript。像VB 6和傳統(tǒng)ASP這樣的舊平臺根本沒有被提及，所以依然在使用這些技術(shù)的公司應(yīng)該盡快地遷移到新技術(shù)上。
不出所料，Microsoft繼續(xù)強調(diào)了依賴注入，特別是它們與ASP.NET MVC及Entity Framework的結(jié)合。企業(yè)試圖集成現(xiàn)場和云架構(gòu)的趨勢讓BizTalk這個一度被認為已經(jīng)死亡的技術(shù)看到了再度煥發(fā)生機的希望。
來自： 昵稱10504424 > 《工作》
0條評論
發(fā)表
請遵守用戶 評論公約
《架構(gòu)師雜志》評述：Scott Guthrie(轉(zhuǎn)與MSDN)
我和我的團隊努力去做的一件事就是及早構(gòu)建原型，構(gòu)建示例應(yīng)用程序，尤其是可以讓客戶親身體驗的演示應(yīng)用程序，我們要向客戶說，"看，你可以這樣來構(gòu)建應(yīng)用程序"。RJ：Microsoft 有開發(fā)人員...
.NET 6 Preview 3 中 ASP.NET Core 的更新和改進
NET 6 Preview 3 中 ASP.NET Core 的更新和改進。blazor.server.js?，F(xiàn)在，使用dotnet watch的 ASP.NET Core 和 Blazor 項目可以獲得對 ...
.Net資訊 | 一大波開發(fā)者福利來了， 一份微軟官方Github上發(fā)布的開源項目清單等你簽收
github地址: https://github.com/dotnet/coreclrASP.NET Core.ASP.NET Core 是新一代的 ASP.NET，早期稱為 ASP.NET vNext，并且在推出初...
iis5.1配置.net網(wǎng)站遇到的問題總結(jié)
配置一個.aspx類型的網(wǎng)站遇到的問題1.IIS 訪問元數(shù)據(jù)錯誤 IIS注冊 IIS重啟。如果在安裝Microsoft .NET Framework 2.0之后在安裝IIS的話...
【翻譯】.NET 5 Preview 1 發(fā)布
當我們期待下一個主要版本.NET 5的發(fā)布時,我們將繼續(xù)將.NET移動應(yīng)用程序模型(Xamarin) 包含在.NET 5中, 繼續(xù)將.NET統(tǒng)一到一個平臺中,.NET 5包含ASP.NET Core、Entity Framework Core、WinForms、WPF、X...
一文看懂：什么是.NET Core以及.NET Core能做什么?
一文看懂：什么是.NET Core以及.NET Core能做什么?與.NET Framework和.NET Core 2.2及以前的版本相比，.NET Core 3.0的速度很快。.NET C...
適用于 Windows 的 Microsoft .NET Framework 4.8 脫機安裝程序
適用于 Windows 的 Microsoft .NET Framework 4.8 脫機安裝程序 簡介 關(guān)于此 .NET Framework 4.8.在 Windows 10 Falls Creator 更新版本 1709、Windows 10 2018 年 4 月更新（版本 1803）、Windows 1...
【官檔整理】Visual Studio vs2017 vs2019 中文離線安裝包下載，替代ISO鏡像
【官檔整理】Visual Studio vs2017 vs2019 中文離線安裝包下載，替代ISO鏡像。NET Core 跨平臺開發(fā)ID： Microsoft.VisualStudio.Workload.NetCoreTools說明： 使用 .NET Core、ASP.NET Core、HTML/Java...
在Win 2003中配置ASP.net環(huán)境
11）與現(xiàn)有 ASP 應(yīng)用程序的兼容性： ASP 和 ASP.NET 可并行運行在 IIS Web 服務(wù)器上而互不沖突；ASP.NET 應(yīng)用程序與 Internet 信息服務(wù) (IIS) 之間的關(guān)系如下：IIS 通過 aspnet_isapi.dll（ASP.NET 的...
微信掃碼，在手機上查看選中內(nèi)容
