消除關于.NET的四個誤解

2019-11-18 11:45:16

字體：大中小

來源：轉載

供稿：網友

　　Visual Studio .NET (VS.NET) 終于發布了，這個新平臺很快在開發人員中流行開來。然而，同任何新的技術一樣，人們對它也有很多擔心、不確定和遲疑——這種想法甚至比其它產品的更多。在同.NET的預期采用者們進行談論時，我發現人們對它的幾個普遍的誤解似乎是造成這種擔心和恐慌的原因。
　　
　　
　　
　　本月我將重點解決人們對.NET的四個最大的、最普遍的誤解。它們不僅會給人們帶來相當大程度的、毫無根據的擔心，在某些情況下，也會讓人們對.NET產生極度的狂熱——這兩種情況都會對成功采用.NET策略造成危害。
　　
　　
　　
　　1. .NET 是基于 Win32 和 COM的
　　
　　Microsoft的組件對象模型（COM）是Windows應用程序組件結構的核心和靈魂。過去，COM是Microsoft操作系統中編寫的應用程序、組件、工具和構架的主要的互用層。如今，.NET和COM的關系使許多開發人員把他們混淆在了一起，他們錯誤地認為.NET是現有的COM結構的擴展和演變。換句話說，許多開發人員認為.NET是基于COM的。
　　
　　
　　
　　實際上，.NET在很大程度上完全是一個新的軟件平臺和組件結構。本質上，.NET把COM歸入到一個“遺留的”環境中。這當然不是說COM應用程序在一夜之間就消失了；它們在未來的幾年中很可能仍然存在。但是，正像Win32/COM在很短的時間內替代了基于字符的DOS應用程序一樣，這個“新產品”將為從COM到.NET的過渡提供一個起點。
　　
　　
　　
　　在向.NET的過渡過程中，你可能會看到投入市場的新的基于COM的應用程序越來越少。漸漸地，隨著時間的推移，.NET將替代基于COM的應用程序，先形成一個混合的模式，然后到2005年，對于大多數基于Microsoft的解決方案，將會形成幾乎100%的純粹的.NET應用程序。
　　
　　
　　
　　開發人員對.NET和合稱為Win32的傳統的“本地”Windows編程APIs之間的關系也感到困惑。Win32描述了一系列具有各種兼容性的操作系統（OS），從現在不支持的Windows 95到Windows xp。雖然將.NET描述成是基于Win32的會稍微精確一些，但這種概念也并不完全正確。
　　
　　
　　
　　的確，.NET構架是依靠于底層的Win32 APIs而連接到OS的。然而，典型的.NET開發人員——不同于如今的COM開發人員（尤其是C++程序員）——將很少直接暴露在底層的Win32層中。作為替代，.NET構架包含它自己的類庫，這個類庫既完全代替了底層的部分Win32層，又作為一個封裝機制將開發人員同其它部分的細節隔離開。正像Visual Basic以前的版本將開發人員同許多Win32的低級的“plumbing”細節隔離開一樣，.NET取得了更大的進展，它提供了一個完整的多語言軟件平臺，該平臺在很大程度上完全從底層的OS隔離出來。所以，從傳統意義上講，典型的.NET開發人員絕對不是Win32開發人員。
　　
　　
　　
　　對許多開發人員來說，他們對COM和Win32的低級的細節問題感到很苦惱，所以.NET很受他們的歡迎。對另外一些人來說，.NET的確讓他們感到恐慌。正因為.NET是“新奇”的，才形成了這種“玻璃杯半空半滿”的情況，我在二月份的專欄中對此做過探討（見資源）。一方面，.NET引進了另人興奮的和有價值的新功能；另一方面，它是以一個新的、未經考驗的應用程序構架為代價的。
　　
　　
　　
　　因為.NET構架包括一個到老的COM世界的有力的過渡，所以相繼產生了另外的誤解。實際上，開發人員可以將軟件服務（如程序、組件、模塊等等）呈現成COM組件，讓.NET組件來使用。同樣，開發人員可以將.NET組件呈現為標準的COM組件。
　　
　　
　　
　　一個.NET開發人員可以完全不用COM代碼來構建整個應用程序系統。他或她也可以構建“混合的.NET”解決方案，將遺留的平臺同新的平臺結合起來。在Gartner公司，我們認為這種混合模式將在采用.NET的最初幾年內占統治地位，因為大多數開發人員在匆忙重寫他們現有的COM應用程序時，發現TCO或ROI優勢并不多。因此，一種“假如沒有被破壞，就不要修理”的策略使人們將現有的COM服務同不斷形成的.NET技術結合起來使用，這種趨勢將至少持續到2004年。
　　
　　
　　
　　.NET采用者的經驗：最不會帶來傷害的采用策略就是避免陷入企圖將你現有的基于COM的應用程序“擴展”得太多這種陷阱。你也應該避免僅僅因為.NET很新就立即完全重寫你現有的系統。對大多數企業來說，將.NET直接但漸進地灌輸到一個軟件開發策略中是最好的方法。采用一個進度，在未來的三到四年內慢慢地、安全地轉移你對低級的COM和Win32 APIs的依靠。
　　
　　
　　
　　2. .NET 是COM+的替代
　　
　　一個“+”號帶來多大的不同。雖然.NET在很大程度上是COM的替代，但它不是COM+的替代——至少現在還不是。這是一個很輕易犯的錯誤，因為COM和COM+這兩個名字很像。雖然COM是一個組件模型，但COM+是一組以中間件為中心的應用程序服務。實際上，雖然它們常一起使用，但COM+和COM在很大程度上是相互獨立的。
　　
　　
　　
　　COM+服務，如異步的消息（MSMQ）和事務處理（MTS），構成了Microsoft的中間件軟件堆棧的支持功能。這些服務共同構成Microsoft DNA 結構的“應用程序服務器”層——盡管Microsoft并沒有明確地用那個術語。
　　
　　
　　
　　雖然.NET構架、組件模型和分布機制（裝配）在大多數情況下代替了COM中同等的概念，但是同在它之前的COM/Win32應用程序一樣，. NET應用程序仍然運用底層的COM+服務。換句話說，.NET構架沒有與諸如MTS或MSMQ之類的服務等同的本地概念。確切的情況是，.NET提供了一組封裝類，作為現有的COM+服務的適配器。
　　
　　
　　
　　這就在.NET開發人員中形成了支持派和反對派兩個陣營。雖然諸如 asp.net之類的功能增強了.NET的可擴展性，但是這種可擴展性在很大程度上仍然取決于COM+ 自身的可擴展性和穩定性。不管怎樣，.NET在可擴展性和穩定性方面并沒有帶來很大的改變。你可以把這一點作為有利于.NET的一個因素（它的底層框架是經受了考驗的），或者你也可以把它作為不利于.NET的一個因素，這取決于你傾向于哪一側市場陣營。業界人士普遍認為Microsoft技術不斷擴大其使用范圍，成為大企業的解決方案。這種觀點的大部分是沒有根據的，或者至少只有部分是正確的，它在很大程度上被競爭者們夸大了。但是，COM+ 仍然擔起了這副重擔，而.NET既不排斥這種誤解，也不對它進行補充。
　　
　　
　　
　　然而，一些主要領域中的早期的成果在表面上是有利于.NET的。例如，我從.NET beta版測試人員和早期采用者那兒得到的關于ASP.NET的穩定性和速度方面的報告就是很好的。由于Internet Information Services（IIS）和Active Server Pages（ASP）眾所周知的不足，ASP.NET的引進就很快流行起來（見資源）。許多開發人員已經發現了直接的、強大的理由（如性能和穩定性）來盡快采用.NET構架的ASP.NET部分，而且還匯報了其相對于ASP的主要的優勢。
　　
　　
　　
　　但是，總體上說，在“首先不傷害”現有的COM+底層框架這個法令下，大多數.NET的功能目前主要集中在生產力、方便開發、一致性等等方面。因此，Microsoft的實質性的R&D力量就主要集中于讓開發人員確信.NET沒有給現有的COM+結構增加相當大的費用。但是.NET并沒有解決當前COM+的許多不足。例如，ASP.NET仍然是IIS的擴展。這就是說，所有IIS的不足（安全性、穩定性等等）在ASP.NET應用程序中仍然存在，就如同它們在ASP系統中一樣。應用程序層已經得到了極大的改進，但是底層的IIS固疾仍然存在。
　　
　　
　　
　　你可以期望， Microsoft在2002年努力推動向.NET移植后，它下一階段的努力將集中在增強可擴展性和性能方面。
　　
　　
　　
　　3. 所有.NET語言都是平等創建的
　　
　　.NET構架引進了很多新的、擴展的技術，它們主要針對各種下一代軟件服務。在這些新功能中，支持多種語言成為與其它競爭平臺——即java——明顯不同的一個功能。與讓開發人員用一種開發語言的Java不同，.NET強調開發人員可以運用他們現有的技術，并把這些技術延伸到.NET中。
　　
　　
　　
　　實際上，Java支持其它編程語言（如Jpython），但它們都沒有引起人們廣泛的關注。例如，雖然Python如今是一個受歡迎的Internet腳本語言，但是Jpython——基于Java的版本——只擁有很小一部分Python用戶。如今，99%的Java應用程序都是用Java語言編寫的。
　　
　　
　　
　　另一方面，.NET強調了其運用現有的技術集合和編程語言的能力，如Visual Basic、Perl、C++、甚至Java。實際上，許多其它的.NET編譯器已經開始出現了，從不知名的編譯器（Scheme.NET）到確實無名的編譯器（SML.NET）。
　　
　　
　　
　　不幸的是，理想的語言“公平競爭環境”只能是種理想。事實離這種承諾相差很遠。一些語言比另外一些語言更適合.NET，在.NET中盡量運用更多這樣的語言就像努力把一個正方形的木樁放到一個圓的洞中一樣。這并不是說這種概念沒有價值；無疑它是有價值的。但是開發人員在實現這種理想前，他們必須對這種承諾采取保留態度。例如，許多編程語言必須被改進，以使它們符合.NET的普通數據類型和運行環境。在一些語言中已經做了重大的折衷，如Perl、Smalltalk和其它語言。例如，ActiveState的Visual Perl和Visual Python不生成.NET本地代碼；作為替代，它們將封裝類用于傳統的運行環境。正如Java的宣傳語“一次編寫，隨處運行”一樣，它從來沒有把這種市場宣傳變成事實，隨著時間的推移，作為“語言公平競爭環境”的.NET將同樣證實，這種說法更多是一種市場宣傳，而不是事實。
　　
　　
　　
　　事實就是只有少量的語言可以支配.NET的開發。在Gartner，我們認為直到2005年，VB和C# 將支配至少80%的基于.NET的開發。所以

上一篇：Java 2 新的焦點子系統

下一篇：.Net和Java應融合