第二章 .NET和C#評說

一，概論
　　Windows內建了COM基礎設施(最成功的跨語言非跨平台機制)而導致了基於COM的ASP的巨大成功。未來的Windows.NET作業系統也許就將把C#.net和VB.net推上新的王者之位。
　　Web Services技術並非微軟獨創，也不是由.NET帶來的。
　　.NET架構由通用語言運行時（Common Language Runtime，CLR）和.NET架構類庫構成。.NET在作業系統之上又加了一層抽象，.NET本身並不是作業系統。
　
　.NET和Java的競爭將長期存在。從微軟pre.NET技術過渡到.NET的創新過程中，肯定會淘汰掉一些抱殘守缺的開發人員。但ASP和
ASP.NET幾乎完全不同。普通ASP開發人員過渡到ASP.NET的痛苦，也許不會少於比起從Visual Basic過渡到Visual
Basic .NET。
　　.NET的最終目的就是讓使用者在任何地方、任何時間，以及利用任何裝置都能訪問他們所需要的資訊、檔案和程式。
　　.NET包括4個重要特點，一是軟體變服務，二是基於XML的共同語言，三是融合多種裝置和平台，四是新一代的人機介面。這四個特點基本上覆蓋了.NET的技術特徵。
　　.NET Framework是開發應用程式的一個新平台。包括通用語言運行環境、Framework類庫和Active Server Pages+

　　CS從C和C++演變而來，本質上是.NET
CLR語義的C風格的文法表達。是MS為.net平台而開發的一種新型程式設計語言:犧牲C++一點底層功能，以獲得更方便和更產品化。C#無疑是.NET水
中最令人信服的魚。在某種程度上可以把CS與當年MS的明星ASP相提並論。我們能夠用CS開發控制台應用程式,Windows應用程式,Web應用程
序.CS會吸引理智面向MS平台的公司與個人，尤其是朝氣勃勃的新人。

二，C#優點
　　1，繼承C++的底層高效的特性，保留了對底層作業系統API的直接調用和指標，保留並增強了枚舉。雖然還達不到純種C那樣快到可以寫系統軟體，但也避免了Java的速度問題以及JNI的笨拙調用C++。
　
　2，繼承Visual Basic高產特性。CS就象一個易學易用的傻瓜自動相機。資料庫緩衝是由OLE DB
Driver自動管理；組件由MTS自動管理(dllhost.dll進程)，.Net Framkwork
Configuration組態工具也簡單至極。對於大部分普通程式員，她具有極大誘惑。
　　3，避免了C++的記憶體管理與指標問題，指標被限制使用，支援記憶體回收(無用記憶體回收),記憶體自動管理。
　　4，CS/.Net架構學習比Java/J2EE輕鬆太多了。
　　5.CLR支援不止一種語言,諸如 CS,VB.NET,Jscript,ASP.NET,C++.Delphi..
　
　6，型別安全：在CS中不能進行不安全的類型轉換象將double轉換成boolean.實值型別(常量類型)被初始化為零值而參考型別(對象和類被編譯
器自動初始化為零值.數群組類型下標從零開始而且進行越界檢查.類型溢出將被檢查.整形數值0和1不再作為布爾值出現.CS中的布爾值是純粹的true和
false值。而且沒有更多的"="操作符和"=="操作符錯誤."=="被用於進行比較操作而"="被用做賦值操作.
　　7.相互相容性：CS
提供對COM和基於windows的應用程式的原始的支援.允許對原始指標的有限制的使用.使用者不再需要顯式的實現unkown和其它COM介面,這些功
能已經內建.CS允許使用者將指標作為不安全的程式碼片段來操作老的代碼.VB.NET和其它中間代碼語言中的組件可以在CS中直接使用.
　　8.
延展性和可升級性：.NET引入了零組件的概念,它們通過其"手冊"具有自描述的功能.手冊確立了零組件的身份,版本,語言和數位簽章等.零組件不需要
在任何地方註冊.要擴充我們的程式,我們只需要刪除老的檔案並用新的檔案來升級它們.不需要註冊動態連結程式庫.升級軟體組件的過程只是一個錯誤探測的任務.
對代碼的修改能夠影響現存的程式,CS在語言中支援版本修改.對介面和方法重載的支援使得複雜的程式架構能隨著時間發展和進化.
　　9，在
Windows平台上.Net
CLR比Java的JRE速度快，聯想到當年MS做的JVM，所以也不是很奇怪。只不過CLR速度足夠快的話，CS位元組碼運行起來，普通應用就不會感覺出
來速度比純本地代碼慢。我的感覺就是這樣，基本上感覺不出來CLR啟動和載入程式集的明顯延遲，而不管用AWT，Swing還是SWT，JVM啟動和載入
類庫的延遲是非常明顯的，這就是真正不妙的地方了，不管Sun，IBM，BEA還是Open Souce 社區，在JVM的效率上還要繼續加油。
　　10，從開發角度來說，同樣的項目CS也要比Java周期短，程式員開發輕鬆很多。
　　開發工具IDE對於GUI開發和公司專屬應用程式意義非凡，Visual .Net Studio比起JBuilder/Eclipse強大得太多。

Java，Eclipse空有一個SWT，卻沒有一個好點的GUI開發環境。JBuilder在AWT，Swing和SWT圖形庫的布局設計上欠缺。當然
這也是受到JAVA的跨平台要求的先天限制不能用像素定位。而VS只在Windows平台上實現，直接就採用像素定位達到“所見即所得 (WYSIWYG)”了。其中CS在
GUI開發方面比VB/VC(MFC)還更加優秀，可與Borland的C++ Builder比美。
　　CS的整個開發過程一體化(SQL
Server/IIS/MTS/IE)，而JBuilder需要考慮DB，App
Server各種不同的軟體實現，在圖形設計器裡面設計EJB，從DB裡面匯入Entity Bean，方便的在所有的主流的App
Server上自動編譯/部署/測試EJB，也算做到極致了。但由於App
Server五花八門和EJB部署本身的高度複雜度的原因，Java的企業開發也是遠遠不如CS來的快捷和方便。
這些原因導致了有時候一個J2EE項目會比.Net開發週期長兩三倍的現象。
　　11，與WEB開發相結合：CS可以將任何組件轉變為WEB服務而跨平台使用，作為後來者的CS對HTML，XML，SOAP（簡單對象存取協議）等WEB新標準結合得較好，方便了應用的擴充。
　
　12，物件導向：CS支援資料封裝,繼承,多態和對象介面(即java中的interface關鍵字).(int,float,double)在
java中都不是對象,但是CS引入和結構體(structs)來使未經處理資料類型變成對象int i=1;String a=i
Tostring();//轉換(或者)Boxing
　　13，C#程式的變數命名方式，不再鼓勵使用老式的匈牙利記法，而推薦使用Pascal記法，這也使得這種語言看上去更加現代。或許在一個一切都是Object的語言裡，為變數加上表示類型的首碼，意義的確不大:)

三，CS的弱點

1、.Net平台支援多語言從技術上和開發角度來說是噱頭，這完全是一個商業陰謀。從ISV角度來看，完全沒有支援多語言的必要，甚至反而是維護升級的災
難。支援多語言的唯一目的在於吸引其它語言的開發人員轉到.Net平台上來，但你會發現用CS比較好，也許就會轉到CS。
2、.Net在將來也不可能支援其它作業系統平台。
　
　CS將把微軟領向何方就一目瞭然了。因為所有項目編寫會只依靠MSIL和CLS
JIT編譯器。這樣CS或任何MSIL前端語言比Java任何時候都快。但很不幸，程式設計和編譯器級的最佳化不能在非微軟的平台上充分利用，想在非
Windows平台上展開.NET，再充分運用它們也是不現實的。
在前面已經提到了.Net和IIS，MTS，SQL
Server等MS平台軟體捆綁的很死，將來還要捆綁更多的MS軟體，像IE，MSN等等。況且.Net依賴Windows也非常緊密。雖然有一個
Open
Source的Mono項目在移植CLR到Linux上來，不過據我來看，也只能做到僅此而已，光把CLR移植過來是沒有多大價值的，需要把IIS，
MTS，IE，MSN，SQL Server等等軟體統統移植過來才能構成一個Linux平台上的.Net，但是這可能嗎？

所以MS開放CS語言和CLI的規範又是一個商業陰謀，表面上裝出一副擁抱開放的姿態，骨子裡面卻壟斷的很。而且從MS的商業行為也可以看出這一點，我們
知道MS把全部身家都壓在.Net上和J2EE陣營競爭，如果.Net是一個開放平台，可以自由移植到Linux上，那麼MS有什麼理由不支援Linux
作業系統呢？如果Linux上的.Net
支援的很好並且普及開來的話，J2EE恐怕只有在AIX和Solaris上苟延殘喘的份了。正是因為MS要把.Net鎖定Windows，所以才害怕
Linux，如果Linux在伺服器市場擊敗了Windows，那麼.Net也只剩下苟延殘喘的份了。所以現在MS視Linux為眼中釘，肉中刺。
所以MS開放CS和CLI，除了做作姿態之外，也可以在更多的OS上普及CS編程的教學，等你們熟悉了CS編程，再乖乖的在我的Windows上替我開發吧。
3、傻瓜式開發，難以進入企業高端領域

組件的自動化管理固然方便，但反過來也讓開發人員喪失了對組件部署的控制能力。在J2EE的世界，EJB或者說J2EE部署者是一個很重要的腳色，絕對不
是可有可無，公司專屬應用程式軟體的運行效能很大程度上依賴對對於中介層組件的部署和效能調節和排錯。所以EJB組件本身就是一個可以通過內部的XML設定檔參
數進行效能自調節的組件，App
Server更是提供了數量龐大，功能繁多的調節和部署選擇。對於一個要求比較嚴格的企業軟體來說，你要提供高效，穩定和安全的運行，手工進行複雜的
tunning是必須的。對於只有一個全自動按鈕的.Net傻瓜相機來說，實在是無能為力。
　　2EE，EJB確實笨拙，開發起來速度也慢，但是一個構造良好，設計合理的J2EE應用經過高手的tunning，絕對是穩如磐石，令人放心。其系統的品質也不是目前的.Net所能比的。
另外.Net還有一個不利的因素是J2EE雖然好像陽春白雪，其實下裡巴人。J2EE既可以採用昂貴的商業App Server和DB的強強組合，也可以採用完全不要錢的免費方案，用成本來衝擊低端市場，所謂各有各的活法。這也是MS比較頭疼的。
　　所以，普通應用會更多的採用.Net/Windows Server/SQL Server。而高端應用更多採用J2EE/Unix/Oracle。
4、分布式領域的不成熟

這體現在幾個方面：

(1) 分布式應用的Session管理

.Net的方案是幾台App Server把全域Session放在一個共用的SQL Server中，實在是...笨拙，不用再評價了！
好好學習一下Weblogic叢集的記憶體複製技術吧！.Net還差的遠呢

(2) .Net的分布式組件

MS的DCOM已經過時了，讓我們看看在.Net裡面如何?分布式組件。

首先在.Net中，普通組件和分布式組件是不同的，在編寫代碼的時候採用的方法就不同。一般組件類似於J2EE中的普通類，分布式組件要採用TCP
Channel或者HTTP Channel來實現，完全兩種不同的編程模型，MS建議採用HTTP
Channel，因為可以穿越防火牆。而對於J2EE應用來說，一般商業組件都採用EJB編寫，分布還是不分布，區別只是部署的時候放不放在一台機器而
已。我沒有仔細研究過TCP Chaneel或者HTTP
Channel，不便於和EJB做對比，不過感覺上，這種Channel的可程式化性和可管理性比EJB還差得遠。

(3) XML Web Services

.Net 上的Web Services加了一個耐人尋味的XML，什麼原因大家體會一下。.Net的Web
Services實現要靠IIS的ASP.Net，把組件以asmx的尾碼放到IIS的Web目錄下，當通過瀏覽器第一次訪問的時候，Web
Services自動編譯和發布，同時產生WSDL。編程起來倒是好方便，但是我隱隱約約的感覺到MS的Web
Services方案另有用意。什麼用意呢？聯想到第(2)點，我覺得MS的XML Web
Services是DCOM的替代品。也就是說MS沒有想到一個更好的解決分布式組件的方法，既可以容易的使用CS編程，同時又很容易部署，很容易進行分
布式組件調用。萬般無奈之下，在上面的Channel方案之外，又搞出這個XML Web
Services，其實就是MS的分布式組件而已。但是HTTP SOAP調用的效率和安全性目前還比較差，還不能和EJB調用相比。況且XML
Web Services仍然沒有解決可管理性的問題，Web
Services的效能調節看來只能靠IIS了。看看吧，EJB確實夠笨拙，但是可程式化能力，可管理能力，至今仍然是MS望塵莫及的。

所以就目前的.Net架構來說，MS還是暴露了在企業領域資曆不夠的弱點，Anders是程式語言設計的天才，設計了Turbol Pascal(也是我最早最喜歡的程式設計語言，在高一開始學習)，Delphi和CS，不過他還不是企業領域的天才。

不排除.Net將來有趕上來的可能，不過目前J2EE在分布式領域還有很大領先優勢，只不過Sun不太掙氣了。

5、看似不錯的Web Form

Web Form也是我覺得很新穎的技術，甚至覺得很有前途，不過實際試用之後，我出了一口氣，“不過如此”

Web頁面由於HTML的限制，表現能力很弱，於是Web
Form技術出來了，就像GUI程式設計一樣來拖拉控制項來設計Web頁面，好像很不錯，其實問題也有不少。因為Web頁面的設計和Web頁面的編程是分離
的，美工人員使用DW設計Web頁面，程式人員內嵌程式碼。程式人員不負責Web頁面的設計，如果都象Web
Form這樣，使用服務端動態產生HTML的表單元素的話，那麼美工人員用DW一開啟Web頁面原始碼，就會發現和在Visual .Net
Studio裡面的Web頁面已經面目全非了。除非Web程式員把美工的活一肩挑，否則Web Form在Web程式員和美工之間的配合就是一個大問題。

6、CS的程式集還不夠豐富

CS出來的時間比較短，而且因為出自MS之手，所以難以吸引大批的Opensource人員，目前Java的Opensource的類庫極大的豐富，幾乎
所有你能夠想得到的功能，一定可以在網路上找到某些人已經編寫好的Java類庫提供你來使用，這種優勢也是很可怕的。CS目前達不到，以後也達不到這樣的
境界。

我對.Net的認識還很不夠，J2EE vs
.Net是一個熱門話題，眾說紛紜。在我粗淺的研究了CS和.Net之後初步的認為，從技術角度來看，如果你對J2EE已經非常精通了，那麼目前也確實沒
有必要轉到.Net上，除非出於市場的需要，或者其它的什麼商業因素。況且在公司專屬應用程式領域，.Net還做得不夠好，仍然有很長的路要走。未來將是.Net
和J2EE共存的局面，就像Windows vs Unix一樣，低端應用更多的採用.Net，高端應用更多的採用J2EE。

我覺得CS從語言角度來說，設計的不夠嚴謹。不單是語言，整個.net體繫結構都能給我這種感覺，很多方面都是為了開發時候的方便和快捷，屏蔽了或者隱藏了很多比較複雜的實現，而這些東西在Java中，都是程式員必須自己手工去處理的。

舉個簡單的例子，對於Java的RMI來說，要編寫interface和interface的實作類別，這個實作類別要可以序列化，並且要用工具產生stub和skelton類。遠程調用的用戶端只需要一個interace類就可以了。

在.net裡面，只需要寫一個實作類別，象interface類，stub，skelton全部都是.net自動產生的，程式員看不到也不知道其內部運作的
情況。這樣情況下，用戶端就必須有一份服務端實作類別的拷貝，而從底層來說，實際上，用戶端需要的是實作類別的介面，而不是實作類別本身。

更進一步，如果使用IIS作為遠程服務端提供者，所有的遠端都寫在設定檔裡面，編寫一個本機物件和編寫一個遠程對象是完全一樣的。

所以我覺得.net像傻瓜相機，程式員的工作已經被極大的簡化了，更何況還有一個高度智能化的IDE來協助你產生代碼。生產效率的提高真不是一倍兩倍，而是五六倍。

Java的體系特別的嚴謹，所有的架構都是一絲不苟，與理論高度吻合，缺點是未免不夠靈活，實現起來比較煩瑣，工作量比較大。不過一個設計優秀的Java軟體是經得起千錘百鍊的，非常穩固。

.net體系設計的更加靈活，極大的提高了生產率。同時也極大得降低了服務端中介層開發的門檻，所以估計未來的服務端程式員將大幅度的貶值，而這就是.net普及的後果。

另外我在使用的過程中發現.net運行交易處理，對象池，分布式應用這些比較高端的東西的時候，消耗的CPU和記憶體資源也是驚人的高，
App Server(IIS, ASP.Net, COM+) + SQL Server 2000這樣的組合跑類似的應用消耗的CPU和記憶體資源已經超過了
App Server(Weblogic Server7.0) + Oracle8.1.7 這樣的組合。

而效率並沒有明顯比Java Based高，甚至感覺.net處理事務，對象池相當的緩慢。

C#速成

http://bbs.dvbbs.net/dispbbs.asp?BoardID=3&ID=452695&replyID=&skin=1

C#和.Net的初步研究 2004-2-10 兗礦集團
C#斷想 榮耀 2002秋