C#和.Net的初步研究 (轉)

C#和.Net的初步研究 (轉)[@more@]

 和的初步研究

研究了一下C#和.Net，有很多體會，好的不好的都有。隨便談談，供大家參考。

先說說它的優點：

1、C#保留了對底層操作的直接和指標。肯定是因為看到了的速度問題以及JNI的笨重，所以在設計C#時特意保留了這些C++的特性，避免了重導覆轍，也使得C#可以用來開發系統。普通應用都是呼叫.Net的集(相當於Java的類庫，程式集裡面都是byte code，不是native code)，對於速度敏感，或者平臺相關型應用，直接透過特定宣告來呼叫 API。這樣就可以功能，和速度都兼顧，解決各種各樣的應用層問題和系統層問題(可以用C#來寫系統軟體了)，用一種語言來解決所有場合的大部分問題，所以MS對C#很有信心。

不過實際上完全用C#開發系統軟體還是不太可能的，畢竟經過C#的包裝以後，比純種的C還是要稍微慢一些，但是肯定比純種的C#位元組碼快太多了。但是當你用C#開發應用軟體的時候，卻不可避免的涉及到底層呼叫的時候，可以方便的直接用C#來實現，不用像Java那樣束手無策的去向C++求救，透過笨拙的JNI呼叫，顯得高明。

2、在Windows平臺上.Net CLR比Java的速度快，聯想到當年MS做的JVM，所以也不是很奇怪。只不過CLR速度足夠快的話，C#位元組碼執行起來，普通應用就不會感覺出來速度比純原生程式碼慢。我的感覺就是這樣，基本上感覺不出來CLR啟動和載入程式集的明顯延遲，而不管用AWT，還是SWT，JVM啟動和載入類庫的延遲是非常明顯的，這就是真正不妙的地方了，不管Sun，IBM，BEA還是Open Souce 社群，在JVM的效率上還要繼續加油。

3、開發工具，老生常談了，不過確實也很重要，對比一下Visual Studio和做的最好的JavaIDE，JBuilder或者吧，不在一個級別上。寫普通的軟體，甚至應用，IDE作用不明顯，特別是對於有背景的人來說，更願意使用純文字工具。但是涉及到GUI開發和企業應用的開發，一個強大的工具是必須的。

GUI開發來說，Visual .Net Studio開發GUI就如同使用VB開發GUI，方便和快捷的難以想像，再加上C#的程式集比VB的集，比VC的MFC的設計優秀的不在同一個級別上。所以在開發GUI方面，C#比VB還更加優秀，基本上和Borland的C++ Builder的水平相當，其操作的便捷還在其之上。

反觀Java，Eclipse空有一個SWT，也不去做一個好點的GUI開發環境出來。JBuilder是公認的最好的Java GUI開發IDE，但是仍然難用的很，為什麼？關鍵處還在於AWT，Swing和SWT圖形庫的佈局設計上。

這3個圖形庫統統都是使用佈局管理器來佈局，佈局好了以後才能放控制元件。不能夠直接拖放控制元件實現絕對畫素定位，也很難實現對控制元件大小，位置的操縱。

這也是有一定的原因，Java為了實現跨平臺的GUI，因此不能夠使用畫素定位，否則在不同平臺會有不同的外觀表現。

而C#就不管那麼多了，既然只在Windows平臺上實現，直接就採用畫素定位(當然佈局定位也可以用)，外觀的控制自然可以“所見即所得”了。

由於這個先天的原因，Java的GUI開發是不可能比C#更方便的，JBuilder能做到這樣，也差不多到極致了，大家也只能忍受了。

企業開發方面，C#需要 SERVER(也可以，但是不如方便)，IIS和MTS的配合，Java需要，App Server的配合。由於C#只管SQL Server和IIS，甚至只管IE，所以Visual .Net Studio可以做的很方便，整個開發過程一體化，不用考慮其它的實現。而JBuilder需要考慮各種不同的軟體實現，特別是App Server，簡直就是五花八門，JBuilder能夠做到這樣，在圖形設計器裡面設計，從DB裡面匯入Entity Bean，方便的在所有的主流的App Server上自動編譯EJB，部署EJB，測試EJB，也算做到極致了。

由於App Server五花八門和EJB部署本身的高度複雜度的原因，Java的企業開發也是遠遠不如C#來的快捷和方便。

這些原因導致了有時候一個專案會比.Net開發週期長兩三倍的現象。

說完了C#和.Net的優勢，再說說不足：

1、.Net平臺支援多語言從技術上和開發角度來說是噱頭，這完全是一個陰謀。
從ISV角度來看，完全沒有支援多語言的必要，難道做一個專案，不同的模組用不同的語言來實現有價值嗎？反過來說，這是一個災難。對於將來的維護的升級來說是一個巨大的災難，用寫的模組，C#程式設計師改不了，用C#寫的模組，J#程式不能維護，人為的造成了混亂。再說C#又不是什麼很難的東西，學習曲線也不高，何必不用C#，非要和自己過不去呢？

支援多語言的唯一目的在於吸引其它語言的開發人員轉到.Net平臺上來，不過當你被吸引轉過來以後，還是發現用C#比較好，用你原來的移植語言不爽，還是不得不重新學習C#，這才發現上了大當了。所以完全是一個商業陰謀。

2、.Net在將來也不可能支援其它平臺。
在前面已經提到了.Net和IIS，MTS，SQL Server等MS平臺軟體捆綁的很死，將來還要捆綁更多的MS軟體，像IE，等等。況且.Net依賴Windows也非常緊密。雖然有一個的Mono專案在移植CLR到上來，不過據我來看，也只能做到僅此而已，光把CLR移植過來是沒有多大價值的，需要把IIS，MTS，IE，MSN，SQL Server等等軟體統統移植過來才能構成一個Linux平臺上的.Net，但是這可能嗎？

所以MS開放C#語言和CLI的規範又是一個商業陰謀，表面上裝出一副擁抱開放的姿態，骨子裡面卻壟斷的很。而且從MS的商業行為也可以看出這一點，我們知道MS把全部身家都壓在.Net上和J2EE陣營競爭，如果.Net是一個開放平臺，可以自由移植到Linux上，那麼MS有什麼理由不支援Linux作業系統呢？如果Linux上的.Net 支援的很好並且普及開來的話，J2EE恐怕只有在AIX和上苟延殘喘的份了。正是因為MS要把.Net鎖定Windows，所以才害怕Linux，如果Linux在市場擊敗了Windows，那麼.Net也只剩下苟延殘喘的份了。所以現在MS視Linux為眼中釘，肉中刺。

所以MS開放C#和CLI，除了做作姿態之外，也可以在更多的OS上普及C#的教學，等你們熟悉了C#程式設計，再乖乖的在我的Windows上替我開發吧。

3、.Net傻瓜相機
眾所周知，C#和.Net的學習曲線比Java和J2EE平坦的太多了。C#學習比Java輕鬆很多，而.Net學習比J2EE輕鬆太多了。那麼Java程式設計師投入多了幾倍的時間和精力就完全沒有價值了嗎？況且從開發角度來說，同樣的專案C#也要比Java週期短，程式設計師開發輕鬆很多，難道這個世道對Java程式設計師這麼不公平嗎？沒有理由下的功夫少，卻得到同樣的收穫，所謂世上沒有白吃的午餐。

經過我對C#和.Net的粗淺研究，我發現其實這是一個傻瓜相機和專業相機的問題。MS做出來的.Net的好學，易用，就如同傻瓜相機一樣，一按就OK，不過照片質量一般。專業相機麻煩是麻煩，不過經過專業人士的手，拍出來的都是高質量的照片，當然你讓普通非專業人員去操縱專業相機確實太勉強了一些。

.Net傻瓜相機確實太方便了，方便到了對的管理都對程式設計師透明化了。緩衝池是由OLE DB 自動管理的；元件的管理是由MTS自動管理的，程式設計師不需要去管這些中間層的問題，開發好元件，用GAC註冊一下就好了，使用的過程中，由.Net平臺的MTS等等實際上完成App Server功能的服務自動處理。.Net Framkwork Configuration工具也是如此的簡單，都是MS在幫你代勞。在執行.Net程式的平臺上注意一下dllhost.dll這個程式，就是專門管理元件的。

不過從反面的角度來看，開發人員喪失了對元件部署的控制能力。在J2EE的世界，EJB或者說J2EE部署者是一個很重要的腳色，絕對不是可有可無，企業應用軟體的執行很大程度上依賴對對於中間層元件的部署和效能調節和排錯。所以EJB元件本身就是一個可以透過內部的配置引數進行效能自調節的元件，App Server更是提供了數量龐大，功能繁多的調節和部署選擇。對於一個要求比較嚴格的企業軟體來說，你要提供高效，穩定和的執行，手工進行復雜的tunning是必須的。對於只有一個全自動按鈕的.Net傻瓜相機來說，實在是無能為力。

所以有所得就必有所失，.Net傻瓜相機在贏得了大部分普通程式設計師的同時，仍然無法進入企業高階領域，或者至少在目前是如此。不過不排除將來有這個可能性。

再看J2EE，EJB確實笨拙，開發起來速度也慢，但是一個構造良好，設計合理的J2EE應用經過高手的tunning，絕對是穩如磐石，令人放心。其系統的質量也不是目前的.Net所能比的。

說到這裡覺得很有趣，MS從開始到現在，幾乎所有的軟體產品都在充當傻瓜相機的角色，就是到了.Net，MS也沒能改變宿命。

Windows vs Unix
SQL Server vs Oracle
.Net vs J2EE

所以我敢斷定，將來J2EE和.Net的處境也會類似今天伺服器市場的Windows Server與Unix，資料庫市場的SQL Server和Oracle。普通應用會更多的採用.Net，而高階應用更多采用J2EE。另外.Net還有一個不利的因素是J2EE雖然好像陽春白雪，其實下里巴人。J2EE既可以採用昂貴的商業App Server和DB的強強組合，也可以採用完全不要錢的免費方案，用成本來衝擊低端市場，所謂各有各的活法。這也是MS比較頭疼的。

4、分散式領域的不成熟

這體現在幾個方面：

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

.Net的方案是幾臺App Server把全域性Session放在一個共享的SQL Server中，實在是...笨拙，不用再評價了！
好好學習一下的複製技術吧！.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的.Net，把元件以asmx的字尾放到IIS的Web目錄下，當透過瀏覽器第一次訪問的時候，Web Services自動編譯和釋出，同時生成WSDL。程式設計起來倒是好方便，但是我隱隱約約的感覺到MS的Web Services方案另有用意。什麼用意呢？聯想到第(2)點，我覺得MS的XML Web Services是DCOM的替代品。也就是說MS沒有想到一個更好的解決分散式元件的方法，既可以容易的使用C#程式設計，同時又很容易部署，很容易進行分散式元件呼叫。萬般無奈之下，在上面的Channel方案之外，又搞出這個XML Web Services，其實就是MS的分散式元件而已。但是HTTP P呼叫的效率和安全性目前還比較差，還不能和EJB呼叫相比。況且XML Web Services仍然沒有解決可管理性的問題，Web Services的效能調節看來只能靠IIS了。看看吧，EJB確實夠笨拙，但是可程式設計能力，可管理能力，至今仍然是MS望塵莫及的。

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

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

5、看似不錯的Web Fo

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、C#的程式集還不夠豐富

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

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

 

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

舉個簡單的例子，對於Java的來說，要編寫interface和interface的實現類，這個實現類要可以序列化，並且要用工具生成stub和skelton類。呼叫的客戶端只需要一個interace類就可以了。

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

更進一步，如果使用IIS作為遠端服務端提供者，所有的遠端處理都寫在配置檔案裡面，編寫一個本地和編寫一個遠端物件是完全一樣的。

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

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

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

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

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