研究C#和.Net的體會
研究C#和.Net，有很多體會，好的不好的都有。隨便談談，供大家參考。
先說說它的優(yōu)點：
1、C#保留了對底層操作系統(tǒng)API的直接調(diào)用和指針。肯定是因為看到了Java的速度問題以及JNI的笨重，所以在設計C#時特意保留了這些 C++的特性，避免了重導覆轍，也使得C#可以用來開發(fā)系統(tǒng)軟件。普通應用都是調(diào)用.Net的程序集(相當于Java的類庫，程序集里面都是byte code，不是native code)，對于速度敏感，或者平臺相關(guān)型應用，直接通過特定聲明來調(diào)用Windows API。這樣就可以功能，效率和速度都兼顧，解決各種各樣的應用層問題和系統(tǒng)層問題(可以用C#來寫系統(tǒng)軟件了)，用一種語言來解決所有場合的大部分問題，所以MS對C#很有信心。
不過實際上完全用C#開發(fā)系統(tǒng)軟件還是不太可能的，畢竟經(jīng)過C#的包裝以后，比純種的C還是要稍微慢一些，但是肯定比純種的C#字節(jié)碼快太多了。但是當你用C#開發(fā)應用軟件的時候，卻不可避免的涉及到底層調(diào)用的時候，可以方便的直接用C#來實現(xiàn)，不用像Java那樣束手無策的去向C++求救，通過笨拙的JNI調(diào)用，顯得高明。
2、在Windows平臺上.Net CLR比Java的JRE速度快，聯(lián)想到當年MS做的JVM，所以也不是很奇怪。只不過CLR速度足夠快的話，C#字節(jié)碼運行起來，普通應用就不會感覺出來速度比純本地代碼慢。我的感覺就是這樣，基本上感覺不出來CLR啟動和加載程序集的明顯延遲，而不管用AWT，Swing還是SWT，JVM啟動和加載類庫的延遲是非常明顯的，這就是真正不妙的地方了，不管Sun，IBM，BEA還是Open Souce 社區(qū)，在JVM的效率上還要繼續(xù)加油。
3、開發(fā)工具IDE，老生常談了，不過確實也很重要，對比一下Visual .Net Studio和做的最好的JavaIDE，JBuilder或者Eclipse吧，不在一個級別上。寫普通的軟件，甚至Web應用，IDE作用不明顯，特別是對于有Unix背景的人來說，更愿意使用純文本工具。但是涉及到GUI開發(fā)和企業(yè)應用的開發(fā)，一個強大的工具是必須的。
GUI開發(fā)來說，Visual .Net Studio開發(fā)GUI就如同使用VB開發(fā)GUI，方便和快捷的難以想像，再加上C#的程序集比VB的控件集，比VC的MFC的設計優(yōu)秀的不在同一個級別上。所以在開發(fā)GUI方面，C#比VB還更加優(yōu)秀，基本上和Borland的C++ Builder的水平相當，其操作的便捷還在其之上。
反觀Java，Eclipse空有一個SWT，也不去做一個好點的GUI開發(fā)環(huán)境出來。JBuilder是公認的最好的Java GUI開發(fā)IDE，但是仍然難用的很，為什么？關(guān)鍵處還在于AWT，Swing和SWT圖形庫的布局設計上。
這3個圖形庫統(tǒng)統(tǒng)都是使用布局管理器來布局，布局好了以后才能放控件。不能夠直接拖放控件實現(xiàn)絕對像素定位，也很難實現(xiàn)對控件大小，位置的操縱。
這也是有一定的原因，Java為了實現(xiàn)跨平臺的GUI，因此不能夠使用像素定位，否則在不同平臺會有不同的外觀表現(xiàn)。
而C#就不管那么多了，既然只在Windows平臺上實現(xiàn)，直接就采用像素定位(當然布局定位也可以用)，外觀的控制自然可以“所見即所得”了。
由于這個先天的原因，Java的GUI開發(fā)是不可能比C#更方便的，JBuilder能做到這樣，也差不多到極致了，大家也只能忍受了。
企業(yè)開發(fā)方面，C#需要SQL Server(Oracle也可以，但是不如SQL Server方便)，IIS和MTS的配合，Java需要DB，App Server的配合。由于C#只管SQL Server和IIS，甚至只管IE瀏覽器，所以Visual .Net Studio可以做的很方便，整個開發(fā)過程一體化，不用考慮其它的實現(xiàn)。而JBuilder需要考慮各種不同的軟件實現(xiàn)，特別是App Server，簡直就是五花八門，JBuilder能夠做到這樣，在圖形設計器里面設計EJB，從DB里面導入Entity Bean，方便的在所有的主流的App Server上自動編譯EJB，部署EJB，測試EJB，也算做到極致了。
由于App Server五花八門和EJB部署本身的高度復雜度的原因，Java的企業(yè)開發(fā)也是遠遠不如C#來的快捷和方便。
這些原因?qū)е铝擞袝r候一個J2EE項目會比.Net開發(fā)周期長兩三倍的現(xiàn)象。
說完了C#和.Net的優(yōu)勢，再說說不足：
1、.Net平臺支持多語言從技術(shù)上和開發(fā)角度來說是噱頭，這完全是一個陰謀。
從 ISV角度來看，完全沒有支持多語言的必要，難道做一個項目，不同的模塊用不同的語言來實現(xiàn)有價值嗎？反過來說，這是一個災難。對于將來的維護的升級來說是一個巨大的災難，用VB.Net寫的模塊，C#程序員改不了，用C#寫的模塊，J#程序不能維護，人為的造成了混亂。再說C#又不是什么很難的東西，學習曲線也不高，何必不用C#，非要和自己過不去呢？
支持多語言的唯一目的在于吸引其它語言的開發(fā)人員轉(zhuǎn)到.Net平臺上來，不過當你被吸引轉(zhuǎn)過來以后，還是發(fā)現(xiàn)用C#比較好，用你原來的移植語言不爽，還是不得不重新學習C#，這才發(fā)現(xiàn)上了大當了。所以完全是一個商業(yè)陰謀。
2、.Net在將來也不可能支持其它操作系統(tǒng)平臺。
在前面已經(jīng)提到了.Net和IIS，MTS，SQL Server等MS平臺軟件捆綁的很死，將來還要捆綁更多的MS軟件，像IE，MSN等等。況且.Net依賴Windows也非常緊密。雖然有一個 Open Source的Mono項目在移植CLR到Linux上來，不過據(jù)我來看，也只能做到僅此而已，光把CLR移植過來是沒有多大價值的，需要把 IIS，MTS，IE，MSN，SQL Server等等軟件統(tǒng)統(tǒng)移植過來才能構(gòu)成一個Linux平臺上的.Net，但是這可能嗎？
所以MS開放C#語言和CLI的規(guī)范又是一個商業(yè)陰謀，表面上裝出一副擁抱開放的姿態(tài)，骨子里面卻壟斷的很。而且從MS的商業(yè)行為也可以看出這一點，我們知道MS把全部身家都壓在.Net上和J2EE陣營競爭，如果.Net是一個開放平臺，可以自由移植到Linux上，那么MS有什么理由不支持 Linux操作系統(tǒng)呢？如果Linux上的.Net 支持的很好并且普及開來的話，J2EE恐怕只有在AIX和Solaris上茍延殘喘的份了。正是因為MS要把.Net鎖定Windows，所以才害怕 Linux，如果Linux在服務器市場擊敗了Windows，那么.Net也只剩下茍延殘喘的份了。所以現(xiàn)在MS視Linux為眼中釘，肉中刺。
所以MS開放C#和CLI，除了做作姿態(tài)之外，也可以在更多的OS上普及C#編程的教學，等你們熟悉了C#編程，再乖乖的在我的Windows上替我開發(fā)吧。
3、.Net傻瓜相機
眾所周知，C#和.Net的學習曲線比Java和J2EE平坦的太多了。C#學習比Java輕松很多，而.Net框架學習比J2EE輕松太多了。那么Java程序員投入多了幾倍的時間和精力就完全沒有價值了嗎？況且從開發(fā)角度來說，同樣的項目C#也要比Java周期短，程序員開發(fā)輕松很多，難道這個世道對Java程序員這么不公平嗎？沒有理由下的功夫少，卻得到同樣的收獲，所謂世上沒有白吃的午餐。
經(jīng)過我對C#和.Net的粗淺研究，我發(fā)現(xiàn)其實這是一個傻瓜相機和專業(yè)相機的問題。MS做出來的.Net的好學，易用，就如同傻瓜相機一樣，一按就OK，不過照片質(zhì)量一般。專業(yè)相機麻煩是麻煩，不過經(jīng)過專業(yè)人士的手，拍出來的都是高質(zhì)量的照片，當然你讓普通非專業(yè)人員去操縱專業(yè)相機確實太勉強了一些。
.Net傻瓜相機確實太方便了，方便到了對組件的管理都對程序員透明化了。數(shù)據(jù)庫緩沖池是由OLE DB Driver自動管理的；組件的管理是由MTS自動管理的，程序員不需要去管這些中間層的問題，開發(fā)好組件，用GAC注冊一下就好了，使用的過程中，由.Net平臺的MTS等等實際上完成App Server功能的服務自動處理。.Net Framkwork Configuration配置工具也是如此的簡單，都是MS在幫你代勞。在運行.Net程序的平臺上注意一下dllhost.dll這個進程，就是專門管理組件的。
不過從反面的角度來看，開發(fā)人員喪失了對組件部署的控制能力。在J2EE的世界，EJB或者說J2EE部署者是一個很重要的腳色，絕對不是可有可無，企業(yè)應用軟件的運行性能很大程度上依賴對對于中間層組件的部署和性能調(diào)節(jié)和排錯。所以EJB組件本身就是一個可以通過內(nèi)部的XML配置文件參數(shù)進行性能自調(diào)節(jié)的組件，App Server更是提供了數(shù)量龐大，功能繁多的調(diào)節(jié)和部署選擇。對于一個要求比較嚴格的企業(yè)軟件來說，你要提供高效，穩(wěn)定和安全的運行，手工進行復雜的 tunning是必須的。對于只有一個全自動按鈕的.Net傻瓜相機來說，實在是無能為力。
所以有所得就必有所失，.Net傻瓜相機在贏得了大部分普通程序員的同時，仍然無法進入企業(yè)高端領(lǐng)域，或者至少在目前是如此。不過不排除將來有這個可能性。
再看J2EE，EJB確實笨拙，開發(fā)起來速度也慢，但是一個構(gòu)造良好，設計合理的J2EE應用經(jīng)過高手的tunning，絕對是穩(wěn)如磐石，令人放心。其系統(tǒng)的質(zhì)量也不是目前的.Net所能比的。
說到這里覺得很有趣，MS從開始到現(xiàn)在，幾乎所有的軟件產(chǎn)品都在充當傻瓜相機的角色，就是到了.Net，MS也沒能改變宿命。
Windows vs Unix
SQL Server vs Oracle
.Net vs J2EE
所以我敢斷定，將來J2EE和.Net的處境也會類似今天服務器市場的Windows Server與Unix，數(shù)據(jù)庫市場的SQL Server和Oracle。普通應用會更多的采用.Net，而高端應用更多采用J2EE。另外.Net還有一個不利的因素是J2EE雖然好像陽春白雪，其實下里巴人。J2EE既可以采用昂貴的商業(yè)App Server和DB的強強組合，也可以采用完全不要錢的免費方案，用成本來沖擊低端市場，所謂各有各的活法。這也是MS比較頭疼的。
4、分布式領(lǐng)域的不成熟
這體現(xiàn)在幾個方面：
(1) 分布式應用的Session管理
.Net的方案是幾臺App Server把全局Session放在一個共享的SQL Server中，實在是...笨拙，不用再評價了！
好好學習一下Weblogic集群的內(nèi)存復制技術(shù)吧！.Net還差的遠呢
(2) .Net的分布式組件
MS的DCOM已經(jīng)過時了，讓我們看看在.Net里面如何實現(xiàn)分布式組件。
首先在.Net中，普通組件和分布式組件是不同的，在編寫代碼的時候采用的方法就不同。一般組件類似于J2EE中的普通類，分布式組件要采用TCP Channel或者HTTP Channel來實現(xiàn)，完全兩種不同的編程模型，MS建議采用HTTP Channel，因為可以穿越防火墻。而對于J2EE應用來說，一般商業(yè)組件都采用EJB編寫，分布還是不分布，區(qū)別只是部署的時候放不放在一臺機器而已。我沒有仔細研究過TCP Chaneel或者HTTP Channel，不便于和EJB做對比，不過感覺上，這種Channel的可編程性和可管理性比EJB還差得遠。
(3) XML Web Services
.Net 上的Web Services加了一個耐人尋味的XML，什么原因大家體會一下。.Net的Web Services實現(xiàn)要靠IIS的ASP.Net，把組件以asmx的后綴放到IIS的Web目錄下，當通過瀏覽器第一次訪問的時候，Web Services自動編譯和發(fā)布，同時生成WSDL。編程起來倒是好方便，但是我隱隱約約的感覺到MS的Web Services方案另有用意。什么用意呢？聯(lián)想到第(2)點，我覺得MS的XML Web Services是DCOM的替代品。也就是說MS沒有想到一個更好的解決分布式組件的方法，既可以容易的使用C#編程，同時又很容易部署，很容易進行分布式組件調(diào)用。萬般無奈之下，在上面的Channel方案之外，又搞出這個XML Web Services，其實就是MS的分布式組件而已。但是HTTP SOAP調(diào)用的效率和安全性目前還比較差，還不能和EJB調(diào)用相比。況且XML Web Services仍然沒有解決可管理性的問題，Web Services的性能調(diào)節(jié)看來只能靠IIS了。看看吧，EJB確實夠笨拙，但是可編程能力，可管理能力，至今仍然是MS望塵莫及的。
所以就目前的.Net框架來說，MS還是暴露了在企業(yè)領(lǐng)域資歷不夠的弱點，Anders是程序語言設計的天才，設計了Turbol Pascal(也是我最早最喜歡的編程語言，在高一開始學習)，Delphi和C#，不過他還不是企業(yè)領(lǐng)域的天才。
不排除.Net將來有趕上來的可能，不過目前J2EE在分布式領(lǐng)域還有很大領(lǐng)先優(yōu)勢，只不過Sun不太掙氣了。
5、看似不錯的Web Form
Web Form也是我覺得很新穎的技術(shù)，甚至覺得很有前途，不過實際試用之后，我出了一口氣，“不過如此”
Web頁面由于HTML的限制，表現(xiàn)能力很弱，于是Web Form技術(shù)出來了，就像GUI程序設計一樣來拖拉控件來設計Web頁面，好像很不錯，其實問題也有不少。因為Web頁面的設計和Web頁面的編程是分離的，美工人員使用DW設計Web頁面，程序人員嵌入代碼。程序人員不負責Web頁面的設計，如果都象Web Form這樣，使用服務端動態(tài)生成HTML的表單元素的話，那么美工人員用DW一打開Web頁面源代碼，就會發(fā)現(xiàn)和在Visual .Net Studio里面的Web頁面已經(jīng)面目全非了。除非Web程序員把美工的活一肩挑，否則Web Form在Web程序員和美工之間的配合就是一個大問題。
6、C#的程序集還不夠豐富
C#出來的時間比較短，而且因為出自MS之手，所以難以吸引大批的Opensource人員，目前Java的Opensource的類庫極大的豐富，幾乎所有你能夠想得到的功能，一定可以在網(wǎng)絡上找到某些人已經(jīng)編寫好的Java類庫提供你來使用，這種優(yōu)勢也是很可怕的。C#目前達不到，以后也達不到這樣的境界。
我對.Net的認識還很不夠，J2EE vs .Net是一個熱門話題，眾說紛紜。在我粗淺的研究C#和.Net之后初步的認為，從技術(shù)角度來看，如果你對J2EE已經(jīng)非常精通了，那么目前也確實沒有必要轉(zhuǎn)到.Net上，除非出于市場的需要，或者其它的什么商業(yè)因素。況且在企業(yè)應用領(lǐng)域，.Net還做得不夠好，仍然有很長的路要走。未來將是.Net和J2EE共存的局面，就像Windows vs Unix一樣，低端應用更多的采用.Net，高端應用更多的采用J2EE。
我覺得C#從語言角度來說，設計的不夠嚴謹。不單是語言，整個.net體系結(jié)構(gòu)都能給我這種感覺，很多方面都是為了開發(fā)時候的方便和快捷，屏蔽了或者隱藏了很多比較復雜的實現(xiàn)，而這些東西在Java中，都是程序員必須自己手工去處理的。
舉個簡單的例子，對于Java的RMI來說，要編寫interface和interface的實現(xiàn)類，這個實現(xiàn)類要可以序列化，并且要用工具生成stub和skelton類。遠程調(diào)用的客戶端只需要一個interace類就可以了。
在.net里面，只需要寫一個實現(xiàn)類，象interface類，stub，skelton全部都是.net自動生成的，程序員看不到也不知道其內(nèi)部運作的情況。這樣情況下，客戶端就必須有一份服務端實現(xiàn)類的拷貝，而從底層來說，實際上，客戶端需要的是實現(xiàn)類的接口，而不是實現(xiàn)類本身。
更進一步，如果使用IIS作為遠程服務端提供者，所有的遠程處理都寫在配置文件里面，編寫一個本地對象和編寫一個遠程對象是完全一樣的。
所以我覺得.net像傻瓜相機，程序員的工作已經(jīng)被極大的簡化了，更何況還有一個高度智能化的IDE來幫助你生成代碼。生產(chǎn)效率的提高真不是一倍兩倍，而是五六倍。
Java的體系特別的嚴謹，所有的架構(gòu)都是一絲不茍，與理論高度吻合，缺點是未免不夠靈活，實現(xiàn)起來比較煩瑣，工作量比較大。不過一個設計優(yōu)秀的Java軟件是經(jīng)得起千錘百煉的，非常穩(wěn)固。
.net體系設計的更加靈活，極大的提高了生產(chǎn)率。同時也極大得降低了服務端中間層開發(fā)的門檻，所以估計未來的服務端程序員將大幅度的貶值，而這就是.net普及的后果。
另外我在使用的過程中發(fā)現(xiàn).net運行事務處理，對象池，分布式應用這些比較高端的東西的時候，消耗的CPU和內(nèi)存資源也是驚人的高，
App Server(IIS, ASP.Net, COM+) + SQL Server 2000這樣的組合跑類似的應用消耗的CPU和內(nèi)存資源已經(jīng)超過了
App Server(Weblogic Server7.0) + Oracle8.1.7 這樣的組合。
而效率并沒有明顯比Java Based高，甚至感覺.net處理事務，對象池相當?shù)木徛Ｒ陨辖榻B研究C#和.Net的體會。
【編輯推薦】
