談Microsoft .NET戰略

來源:互聯網
上載者:User
戰略 在蹉跎中一路前行



——談Microsoft .NET戰略



Eric Liu(劉如鴻) 2004年《程式員》雜誌第六期

題記

四年的時間對於曆史而言只是滄海一粟,而對於一個商業公司而言,卻足以重生幾回。從微軟提出.NET戰略到現在也接近四年了,而今的我們應該怎樣去看待.NET四年走過的曆程,怎樣去評價.NET戰略。





從職業角度來講,過去的半年實在是瘋狂,絕對的瘋狂,至少我是這樣。其中有很多原因,但最重要的一個原因實際上是我們公司正在經曆的變遷。而今天所作的介紹從某種意義上可以說,許多人、尤其是我,度過了無數個不眠之夜、花費了無數心血來認真思考這場變革。但是從某種意義上講,正是這一變革,促使比爾·蓋茨在年初作出了重要決策。我們確實花費了全部時間來認真考慮新一代的互連網會是什麼樣,怎樣把如此眾多的部分,包括我們已經做過的一些開發,完美地結合起來,繼續保持世界領先地位,成為100%的比爾·蓋茨時代。

微軟總裁兼首席執行官——史蒂夫·鮑爾默

.NET的激情起航
2000年6月22日,這是一個所有“微軟人”都應該記住的日子,因為從這一天起,微軟公司將下一場賭注,一場押上全部身家的世紀豪賭——這一天,比爾.蓋茨向全球宣布其下一代軟體和服務,即Microsoft .NET平台的構想和實施步驟。新一代的Microsoft .NET 家族產品和技術替代了此前“下一代Windows服務(NGWS)”的提法,它涵蓋了協助軟體開發商構建下一代互連網服務和給予新一代智能互連網裝置強大功能的軟體。此外,微軟還宣布了基於.NET 平台的新產品計劃,其中包括新一代的微軟Windows作業系統、Windows DNA伺服器、微軟Office、MSN互連網網路服務、Visual Studio開發系統。

這樣的決定對於當時已經全球領先的微軟而言,無疑是“押寶”,將未來十幾年內的發展押給了他們構築的.NET,當然也正是從那一刻開始,這家全球最大的軟體公司也會不會遺力的去推進這個“偉大的夢想”。

那時的.NET
什麼是.NET?.NET有什嗎?有人也認為是微軟故意模糊概念,實際的.NET是Windows DNA(Distributed Network Architecture)和COM+的一個延續,在本質上沒有改變。雖然這樣的理解有時偏頻,但是問題是明顯的,我們不是那麼容易的理解“什麼是.NET”。

2000年微軟的白皮書這樣定義.NET:Microsoft® .NET 是Microsoft XML Web Services 平台。XML Web Services 允許應用程式通過 Internet 進行通訊和共用資料,而不管所採用的是哪種作業系統、裝置或程式設計語言。Microsoft .NET 平台提供建立 XML Web services 並將這些服務整合在一起之所需。對個人使用者的好處是無縫的、迷人的體驗。

我們可以清楚的看到微軟對於.NET的理解是XML Web Services的平台,一切皆是服務,下一代的Internet應用將是依賴於Web Service來構建,Microsoft .NET 平台由以下技術構成:

l .NET使用者體驗

l .NET基礎設施和工具

l .NET服務構造塊

l .NET裝置軟體





使用者永遠是上帝,脫離使用者討論戰略沒有實際意義,為此除開倡導的平台核心技術以外,微軟還承諾對於個人使用者提供.NET使用者體驗,其中包括:

Windows .NET

MSN .NET

使用者訂購服務

Office .NET

bCentral for .NET

Visual Studio .NET








從這些文字我們可以看出,微軟幾乎可以將自己的全部產品加上“.NET”的字眼,但是那是不是因為著這就是“.NET”?

Everything is .NET
大概是為了強化.NET在人們心目中的印象,微軟此時開展了一場dotnetialization(.NET化)運動,幾乎所有傳統的、創新的和虛構的產品都被打上“.NET”的標籤。

為了擴充.NET戰略的宣傳,微軟將其很多仍使用傳統技術的產品都加上了“.NET”字眼。最典型的莫過於2000年底發布的.NET Enterprise Server系列。這套伺服器軟體雖然打上了.NET標籤,但與.NET技術沒有任何關係。

真正創新的思想是Web Service。微軟當時極力推動Web Service從概念走入應用的最核心。

此外,微軟還虛構了、或者至少是過早描繪了一些新的、以“.NET”命名的產品與服務。

一切都是.NET,微軟這樣做的結果就是將.NET這個品牌叫得路人皆知,而其實質概念則幾乎沒有人瞭解。除了提供一些開發工具的支援,其他方面的.NET推進有點做作的感覺,更加實際的來說.NET戰略只是一個CLR的平台,其他方面的概念解釋都讓人牽強。









艱難晦澀的.NET改變終於帶入微軟走入了一個尷尬的境地,.NET Enterprise Server就如同水中望月,而Office XP的推出除了絢麗的圖形表現介面以外,也沒有太多東西讓人發現和.NET有關,這是一段迷惘而痛苦的歲月。

迷惘
經過一年多的喧囂,.NET已經漸漸熱起來,越來越多的人開始使用.NET,至少開始關注這個平台,C#的正確發音已經盡人皆知。但是,看得出來,微軟自己對於.NET的態度已經發生了微妙的變化。原來的計劃太龐大,即使微軟這樣的巨人也無法掌控。前面的路應該怎麼走?微軟也產生了迷惘。

2001年5月31日Office XP正式發布,它顯然不是“傳說”中的Office.NET。微軟強調這個XP版本加大的是“體驗”(experience)及其網路的整合,而“使用者體驗”和與網路的融合都是“.NET戰略”的一部分。但是,實質的改進有什麼呢?除了返璞歸真的平面圖形菜單(戲劇性的是這樣的介面成了日後眾多軟體介面模仿的對象),和內建支援了SOAP工具包及其聯機搜尋能力,我們發現和當初預想的Office.NET有天壤之別。

Office開發採取滾動方式進行,也就是在發布Office XP之前,下一版Office已經在開發中。據說部真的正在開發一個雄心勃勃的Office.NET。在這一激進的計劃中,所有的訪問都是通過Web Service來完成的,應用程式與網路的融合史無前例。不幸的是,這個產品最終流產,並且直接導致一個副總裁的辭職。究竟是技術上太不現實,還是微軟意識到這個產品無法被使用者接受?我們已經不得而知。

如果說Office曾經太激進,那麼那些支援IT應用基礎架構的應用伺服器又是如何呢?在商業應用中的Commerce Server 2002,Biztalk Server 2002,Content Management Server 2002等等,雖然在一定程度加上了.NET Framework的支援,但是感覺有點是被微軟強行聯姻的“親家”罷了,Visual Studio .NET對於其開發的支援依然是一種有心無力的感覺,並且這寫伺服器提供的並不是完整的託管類庫,很大一部分功能仍然需要通過COM的方式來完成訪問。.NET是一個龐大的戰略,但是在短短的時間內希望完成到一個新的平台的遷移不是那麼容易的事情,而此時.NET Enterprise Server系列的2002版本雖然在一個.NET的名頭下依然是一個伺服器叢集,但是根本無法體現出.NET曾經的設想。

此時的VS.NET有點孤軍奮戰的感覺,畢竟和其他應用伺服器的結合不是那麼盡如人意,並且在Managed C++方面的表現也不足以作為系統級開發的利器,因此還是有些人在等待,而不會去考慮將已有的應用全部遷移到.NET平台上來。

所有這些情況,不僅體現了,同時也導致了微軟的困惑。一個技術概念,如果不能與切實可用的產品結合起來,就會變成空中樓閣。

















對於使用者而言,最重要的是能夠實際帶來什麼,而不是僅僅帶來概念,經曆了那段迷惘,微軟對於.NET的理解終於“塵歸塵,土歸土”,穿過水花鏡月,一路堅定的走來。





務實
? 2002年7月24日,比爾•蓋茨在一個內部講話中承認說,2000年9月推出的.NET企業伺服器稱作.NET“是有點草率”,也正是從這個時候開始微軟真正開始反思.NET戰略是否太過泛濫,是否超出了他們所能夠控制的範圍。

在反思中摒棄浮躁,在務實中前行,經過兩年時間的喧囂和反思,.NET正在一點一點地走進現實應用。

? 2003年4月25日,曾被命名為Windows .NET Server的Windows Server 2003正式發布。Windows Server 2003此前曾四易其名,它是第一個內建支援.NET Framework 1.1的Windows作業系統,因此有資格戴上.NET的標籤,但最終確定的名稱中並沒有包括“.NET”字樣,出乎很多人的預料。

同日,微軟發布了基於.NET Framework開發工具的第二個版本,也就是Visual Studio.NET 2003,經曆了一年的發展,2003版本終於被越來越多的開發人員所接受,除了修正了2002版本的一些細節性錯誤,在類庫方面也更加強健和良好的相容。

也也就是從此刻開始,VS.NET成為一個最強大的開發平台,多語言整合的開發環境,開發人員不僅可以開發傳統的Windows應用,能夠開發Web應用程式,同時在移動開發,企業級組件方面都提供了良好的支援。

Office.NET已經漸漸淡去,此刻的微軟也明白一相情願設計一個完全以Web Service為中心的Office版本至少在今天是不可行的。2003年10月27號的時候發布最新版本的Office 2003中,啟用了一個比較保守的命名——Office System 2003。從此Office不再是一個純粹的用戶端軟體,而是一個完整的公司資訊應用平台,不過相對於神話般的Office.NET,還有很長的路需要走,不過我們可以肯定,神話僅僅是神話,這個時候的微軟已經知道.NET對於使用者意味著什麼。

在伺服器系統方面,.NET Enterprise Server有點盛名難負,更加直接的來說是一個虛構的名字。為了更加貼近實際情況,微軟將新版伺服器系統命名為Windows Server System,旨在建立一個深度整合的伺服器基礎結構,而從使IT專業人員能夠將精力集中到滿足業務需求方面。

這一切表明,微軟在.NET的推廣策略上已經趨於務實。事實上,一項新技術,必須有現實的產品支撐。微軟一向的做法,是將新技術與自己的強勢產品結合,從而讓終端使用者的需求推動開發人員轉向微軟技術。然而,在.NET推廣之初,這一策略並沒有很好的貫徹。只是經過了這個務實階段之後,微軟才重新回到了自己的正確路線上。將.NET技術與Windows和Office兩大拳頭產品結合,這表明.NET已經邁上穩健發展之路。


未來展望
Longhorn需要到2006年才能夠發布,我們完全可以認為,這個就是四年以前微軟提出的.NET戰略時希望達成的夢想之一,整合互聯,同時擁有一個非常出色的使用者體驗。微軟當初承諾在三年內實現這些基礎架構的建設,現在看來這個時間恰好需要多一倍,也就是整整六年的時間。這個號稱完全重新構建的作業系統才能夠稱得上.NET作業系統,關於其中的Avalon(圖形渲染技術)、Indigo(通訊子系統)、WinFS(檔案儲存體系統)還有純粹的.NET編程介面WinFX。

相信2006年的Longhorn發布的時候,.NET應該已經得到業界的認同,並且已經出現了相當部分基於.NET的成功案例,對於.NET的FUD(Fear/Uncertainty/Doubt,恐懼/不確定性/疑慮)也已經煙消雲散,.NET和J2EE真正意義的站在同一個水平線上去對話。

而在Longhorn中的Indigo子系統,則以一種更加透明的方式來實現系統的部署,於是“一次編寫,多次部署”也成為可能。隨著.NET提出微軟一直倡導的Smart Client技術也得到完美的體現,這個時候已經可以不去考慮案頭和瀏覽器的區別,如果說有,那麼只是一種部署方式的差異,而解決這個問題的核心在於XAML及其和Win32 API等同的WinFX技術。

“一切皆是Web Service”,那個時候的確可以做到當初.NET戰略希望的所有子系統都通過Web Service通訊(當然了,那個時候的Web Service不再是今天的效率)。期待總是期待,畢竟還有兩年的時間去觀望,也許到了日後一切全部變了樣。

但是我們相信,未來的.NET會成功,就如同微軟一貫以來的成功,於是今天我們不是考慮是否使用.NET而是考慮何時選擇.NET,當然,每一次的選擇和放棄都是一種痛苦。









不知道是刻意或是純粹出於偶然,營銷名詞和技術名稱以及通用詞彙竟然都在同一個時間點代表了同樣的意義:過去與現在,傳統與流行。

.NET重要技術思考
.NET Remoting
從COM(Component Object Model)時代到DCOM(Distributed COM),微軟扮演了一個推動者的角色。如果說COM提供了一個Windows平台上的對象通訊技術,並且逐漸成為應用程式之間彼此通訊及互動的技術主流,那麼DCOM則是解決了電腦的通訊和互動技術。

COM的著眼點是在於同一台電腦上不同應用程式之間的通訊需求,跨到另外一台電腦之外,就不是一開始COM所設想到的領域。所幸跨程式的通訊和跨電腦的通訊差異僅在於通訊協議的處理(也就是定位問題),對於資料交換上型別差異的處理並不會因此而有區別。所以要讓COM的環境能更進一步延伸到跨電腦的領域,只要妥善解決電腦定位的需求,就有機會克服。同樣幸運的是,COM在一開始的設計中完全不去碰觸跨電腦的問題,使得要在COM的架構之上再架上一層跨電腦的處理環境並不會去破壞到原本的架構。於是COM的網路延伸版本DCOM(Distributed COM)就此出現,專責讓COM組件可以在網路環境下持續提供服務。DCOM最主要處理的是兩個議題,第一個議題是網路通訊能力,第二個議題則是許可權的問題。之前COM是在同一台電腦中找特定的組件,而DCOM則要更進一步去找網路上的某台電腦,之後沿用COM的機制找到電腦上的組件。

到了.NET當中,跨電腦的問題同樣也需要對應的技術進行處理,.NET Remoting就是一個對應於DCOM的技術,它讓存活在不同應用程式定義域(AppDomain,一個 .NET中的新概念)、不同執行程式、以及不同電腦上的對象能夠順暢的進行溝通協作。在累積了長期以來分布式應用的經驗之後,微軟沒有理由把東西設計的更難用。從某種意義來說,.NET Remoting提供了比過去更便於使用的開發架構,用來來支援跨電腦的溝通作業,省卻開發人員建立分布式應用程式時必須花費的心力,不過這樣一個“出色”的分布式應用應用程式框架並沒有得到本來應該得到的“待遇”。相對於Java的RMI而言,它更加簡單同時保持設計方面的彈性,同時擯棄了DCOM的一些缺點,在對於一個前後端必須以有狀態緊密結合方式進行互動作業,同時又期望呼叫和資料交換的動作上能以最有效方式進行的環境而言,.NET Remoting是一個比較恰當的選擇方案。

可是問題在於微軟本身對於XML Web Services的狂熱推崇讓.NET Remoting迷失了本來屬於它自己的陣地,也就是說XML Web Services的過火讓.NET Remoting忘記了自己應該承擔的角色,於是在開發人員眼中成為了一個“可有可無”的作品,至少對於很多開發人員而言,在需要建立分布式應用程式的時候首先考慮的是XML Web Services,而在於企業內部應用,特別是在可以控制伺服器和用戶端平台的情況下(比如完全基於.NET平台的應用),Web Service因為效率等等各個方面的原因並無法體現出優勢。從技術本身來講,.NET Remoting是一個非常出色的架構,但在商業方面,這是一個失敗,畢竟,設計一個出色的產品然後束之高閣難免“不像話”。

.NET Remoting恰恰是這個戰略的犧牲品,雖然擁有與生俱來的優點,不過依然生不逢時。

Enterprise Services
從一個很直接的感覺來說,Enterprise Services只是對於COM+的一個封裝,從使用方式和技術實現本身而言,和VB或者VC下使用COM+服務沒有本質的區別,而更多的只是在於多了一層Managed 程式碼的封裝,讓.NET開發人員能夠比較順利的使用這些服務的功能。

相對於J2EE平台上的應用伺服器如BEA的WebLogic,IBM的WebSphere或者開放原始碼的JBoss,微軟是希望能夠在企業級應用之中分一杯羹,可是因為先天不足的原因,在公司專屬應用程式中需要的事務、Server Load Balancer、容錯移轉等等技術中的表現不是那麼盡如人意,至少缺乏非常清晰的應用伺服器(Application Server)的概念,雖然微軟不止一次的強調作業系統本身就是一個應用伺服器,一個IT資訊的基礎結構。但是從開發人員實際的使用來看,這是一個“晦澀難懂”的產品。

雖然.NET Framework改變了很多東西,但是作為企業級應用中最重要的支撐技術——事務和服務,並沒有得到同等程度的發展,我想這個也就是很多大型公司專屬應用程式目前不選擇.NET的一個理由吧,畢竟從MTS——COM+——Enterprise Services,這一路走來微軟始終不是提供一個非常透明的機制讓開發人員去控制各個環節(可能和微軟一貫以來的策略有關,只是關心最廣泛的應用而不是最高端的應用),而.NET中的所謂企業服務,和競爭者提供的相當的EJB還是有比較大的差距,這是一個日前的微軟無法解決的軟肋。

Web Service
從一開始,微軟就將其作為“重頭戲”推出,並且饒有意思的增加了XML,然後那個“XML Web Services”就成為了.NET戰略中一個非常重要的術語,就如微軟的白皮書所言“Microsoft® .NET 是Microsoft XML Web Services 平台”,微軟通過.NET來改變現有的互連網絡結構,“Windows正在走向過去”這樣的宣傳是在於希望各個子系統之間的通訊完全基於Web Service,那樣的話,作為Win32開發人員一直困擾的組建註冊,分發等等一系列問題都能夠得到解決,並且能夠用更多的語言更多的平台去開發應用。



“一切皆是Web Service”,這是一個冒進的舉動,至少對於4年以前的世界,而這四年以來,雖然Web Service有很多很多的優點可以讓我們“歌功頌德”,但是不是“萬金油”,比如一直稱垢的效能和安全問題也阻礙了Web Service一統天下,於是其他分布式應用架構在特定的領域依然能夠有自己的生存空間。



這一次,微軟高估了Web Service,雖然目前的.NET是實現XML Web Services最好的平台,Visual Studio .NET也提供了從上至下的封裝,讓開發人員完全可以不關心協議的底層實現,比如SOAP,比如對象序列化,比如WSDL,因為一切的一切都可以在IDE中自動完成。我們不否認因為.NET,Web Service從概念已經走進應用,而WSE 2.0的出台更加Web Service具備了互操作能力,不過依然無法改變開發人員的觀點,只有在企業外網應用整合或者內部異種平台整合的時候才能夠體現出優勢,在於需要高度響應和服務支援的應用方面,Web Service只是一個臆造的神話。



ASP.NET
我們無法否認,這項技術對於開發人員而言是一個顛覆性的改變,從靜態HTML到CGI再到ASP/JSP/PHP時代,我們都必須去瞭解HTML,瞭解HTTP,對於高水平的開發人員而言,需要掌握的還遠遠不止這個,在指令碼橫行的時代,我們必須很清楚的去瞭解實現的各個細節,包括HTML,JavaScript,CSS,還有和伺服器相關的Request、Response。最直接而言,開發人員必須嚴格控制所有HTML及其相關內容的產生,指令碼帶來的只是一個相對於CGI層次更加進階的“自動化”罷了。

然後,ASP.NET將這一切完全改變,WebForm讓Web開發人員能夠和Windows開發人員一樣處理頁面事件,同時可以完全的訪問強大的.NET Framework類庫,而且預先編譯機制解決了ASP一直以來的效率低下問題。而在伺服器端的設計,在原先ISAPI的基礎上從新實現了HttpHandler和HttpMoudle,從而為開發人員提供了高度擴充的可能,而日前比較成熟的WebLog引擎.Text正是這些技術的經典之作。

XML Web Services的內建整合則使ASP.NET成為Web Service應用的最好實現,日前市場上相當大部分的Web Service都是基於ASP.NET的,在這點方面ASP.NET已經遠遠超出Java社群的技術,包括JSP,包括Struct,包括JSF還有其他相關的Web應用技術,在ASP.NET都能夠得到非常好的整合。

我們不可能否認這個事實,相當大一部分(我個人認為是大部分)的開發人員轉向.NET是因為ASP.NET,對於ASP開發人員而言,ASP.NET提供了更加強大的功能,很多在ASP中必須相依元件技術來解決的問題比如檔案上傳在新的平台上已經成為內建支援,當然更加重要的是依賴Visual Stuio.NET強大的整合式開發環境能夠成倍的提高生產率。而另外平台的開發人員轉向ASP.NET我想也是因為彈性的設計及其便捷的開發,我相信沒有太多人會懷疑ASP.NET已經走在Web開發的最前沿。

當然,任何事情沒有絕對的完美,在.NET Framework 1.1(也就是.NET的第二個版本)之前,太多的Postback也是讓開發人員抱怨之處,而且採用WebForm的開發方式讓很多開發人員不是那麼容易的處理用戶端指令碼,所有的事件實現都是依賴於ViewState,因此在低頻寬下的網路應用,不斷地提交也讓有些使用者感到“惱火”。

這個世界沒有絕對的完美,但是會一點一點走向完美,也許ASP.NET 2.0就有太多東西值得期待。







ADO.NET

相信大家不會忘記ADO(ActiveX Data Object),我想Windows上面資料庫開發流行它功不可沒,通過統一的介面來實現對於資料庫的訪問,從而屏蔽複雜的資料庫訪問協議。而到了.NET時代,ADO.NET進一步將資料訪問“進化”,不要以為ADO.NET只是ADO的一個升級,在ADO的技術上提供了一個託管類庫,除了都是資料訪問架構,其他沒有太多本質的關聯。



雖然ADO.NET帶來的震撼遠遠不如其他技術,可依然有很多東西值得我們去欣喜,畢竟創新總是一件好事情,何況是這個最成功的軟體公司帶來的創新,那麼我們就來看看到底帶來了什麼:



1. 除了提供了傳統ADO的Connection,Command以外,我們意外的沒有看到Recordset這樣的對象,而是提供了DataReader用來處理向前滾動的資料訪問,最最重要的是加入了DataSet這樣的概念,因為如此,我們能夠實現很多資料庫應用中需要的“Disconnected Application”,能夠實現“InProc-Database”,而這一切,通過DataSet能夠得到很好的解決。



2. 以更加透明的方式提供了資料庫連接池,同時開發人員能夠通過變成的方式控制具體的運行方式。



3. 提出DataAdapter,讓開發人員能夠以一種統一的方式去訪問異種資料庫,唯一的區別在於具體適配器的實現不同罷了。



4. “Typed Dataset”讓開發人員能夠非常方便的將DataSet 中的Table、Field映射到自訂類。



5. 對於XML提供了良好的支援,所有的DataSet都能夠非常容易的系列化或者反系列化成XML文檔。



當然ADO.NET不是萬能的,在資料持久層(Data Presistent Layer)方面的支援顯然不如Java,到現在為止都沒有一個很好的O/R Mapping工具,而Java方面的Hibernate已經非常成熟,ADO.NET 2.0中的ObjectSapce也許能夠改變目前的現狀,就讓我們耐心去等待,雖然需要到2005年。















“我們離破產只有18個月”,這是全球最成功的軟體公司對於自己的告誡,於是他始終走在最前端,通過概念——務實——再概念的迴圈一次又一次的改變自己,同時改變了整個世界。

.NET改變了什嗎?
Microsoft,是否依舊“Micro”?
原先的Microsoft已經不再“Micro”,20多年的高速成長,這家從PC起家的軟體公司已經早早稱霸全球,除了在PC機方面保持絕對的壟斷優勢以外,在伺服器市場,也已經發起對於高端應用的衝擊,Windows 2000就是這個戰役的經典之作,按照一貫的策略,微軟依賴其價格優勢和最簡單的操作介面一點一點地換取中小企業的“芳心”,而對於大公司專屬應用程式,雖然還無法改變其“小丑”形象,但是顯而易見,那樣的關係越來越“曖昧”。

評論界很多人都認為微軟是一個以銷售起家的公司,畢竟微軟的技術從來不是最好,卻能夠笑到最後,我們無法否認過去很長一段時間微軟是依靠Windows和Office的銷售來支撐整個公司的高速運轉,但.NET戰略的推出則展現出微軟從銷售型轉向服務型企業。畢竟隨著技術的發展,在作業系統和辦公軟體上面的利潤已經越來越透明,加上Linux的衝擊和微軟自身舊產品如Windows 98,Office 97等等已經足夠“好用”,這樣帶來的結果必然是企業IT採購成本的大幅度縮減,微軟自身也必須找尋更好的商業模式來擷取穩定的收入。

將“Windows時代”帶入“.NET時代”,對於微軟公司而言,需要做的有很多很多,包括自身定位,包括如何打破使用者的顧慮和恐懼,當然還有一直以來不是很友好的公關形象。於是.NET戰略成了微軟一個新的戰場。

改變了開發人員
很多人在會抱怨新的技術更新太快了,如果跟著微軟走總是需要不斷地學習新技術,而相對來說其他的技術更新就沒有如此之外,至少能夠保持一段時期的穩定,這點就從C++那麼多年以來的發展還有Java就可以看得出來。

不過,世界總是在變化,有很多東西總是在不斷改變,與其拒絕變化然後徘徊不前,不如去擁抱變化,當然這裡提到的並不是盲動的跟隨改變,然後成為“語言學習機器”。4年的發展,.NET已經漸漸的成長為可以和J2EE對抗的應用平台,並且在中低端的應用開發中,能夠顯著的提高生產力,這是何樂而不為。

不過微軟在.NET的營銷並不是非常成功而乾脆,至少在Web Service方面對於廣大的開發人員是一種誤導,這個世界沒有絕對的“銀彈”,Java不是,.NET也不會是,而XML Web Service在微軟自身的定位的反覆不定也讓人有點疲憊。





帶來一個新的選擇,帶來更高的生產力,帶來一種新的理念, 作為一線的開發人員,我們曾經為選擇一個工具或者平台困惑、迷惘、狂熱、追逐,最後堅定或者放棄。



這個世界本來就是一個需要不斷探索的世界,.NET同樣如此。從總體上來說.NET,經曆從狂熱到迷惘,在到務實,從而逐步走向成熟的過程。







相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。