Mono 2.0 是一個里程碑版本，為Linux下.Net程序開發創造了基本框架。不考慮穩定性和可靠性，從功能上考慮，Mono 2.0的Microsoft 兼容的API有了大幅的改進，ADO.NET、ASP.NET 和 Windows.Forms 三大應用API，使得為Linux平臺遷移大量的網站、客戶端程序和數據庫應用程序成為可能。

     作為開發平臺，Mono平臺的兩大致命缺點是，缺乏有效數據庫方案集成和開發工具集成。

缺乏集成數據庫支持，是一個致命弱點。雖然靈活的中立API可以使得開發人員靈活的選擇數據庫，但是，作為平臺提供商，要銘記一點，那就是，數據是軟件的命脈，程序只是表達工具，一個開發平臺所展示給開發者的藍圖是處處離不開數據庫的。

一個平臺應該考慮提供兩種數據庫解決方案，一個是基于文件的無服務器的方案，另一個是基于服務器/客戶端的方案。Microsft.Net 平臺推廣的就是 Access 和 SQL Server，Access 作為桌面數據庫，是非常成功的產品。借助VBA可以將Access數據庫的能力發揮到極限。是否記得，在ASP/ADO時代，當ASP還很流行的時候，那時我們用的是托管主機，我們經常費盡心思保護我們的數據庫；Sql Server 扮演了另一個角色，Sql Server 一直是微軟數據中心戰略的核心，雖然微軟的平臺以優秀的可擴展性著稱，但是誰愿意為其他數據庫花時間手動開發數目巨大的代碼呢。因為客戶需要，微軟提供了SSCE，使得Sql Server也可以勝任桌面數據庫便利性和部署的要求。移動版本的數據庫就得依靠Sql減縮版了，這不是SSCE所指的那個版本。不要忘記了微軟已經不再開發新版的Visual Foxpro 了，我個人非常喜歡Visual Foxpro，作為數據庫，它提供的程序設計功能要比VBA更合適，并且數據庫系統的性能和功能也比Access好的多；作為編程平臺，它和數據庫的結合比任何其他方案都更緊密，更易于操作。微軟之所以放棄了Visual Foxpro，是因為微軟不想讓自己數據庫方案混亂的狀況繼續下去，一個桌面數據Access和一個服務器數據庫Sql Server 完全滿足自己的平臺和市場戰略。.Net 方案從一開始就準備放棄Visual Foxpro在.Net 數據庫戰略一等公民的權利，看看.Net對Visual Foxpro的支持就知道了，Access 完全是一等公民，應對中低端的數據方案需求，至少從開發環境的支持上看是這樣的。

      看看Mono平臺，Mono 現在數據庫平臺的方案部署跟Sun公司當年的差不多，廣泛使用開源的數據庫和驅動提供者，我覺的Mono平臺對自己數據庫方案的定位也是很明顯的。在低端使用SQLite數據庫，這是一個性能優秀、定位明確，并且廣泛使用的數據庫，在高端使用Postgresql數據庫。.Net平臺的戰略規劃是微軟做的，因此Novell 必須找到一款能夠替代Sql Server 的數據庫，否則Novell 必須依賴Sql Server，那么Mono開源的招牌就說不過去。

　　在這里插上一段，首先，Mono是Novell公司的一個項目，旨在提供Linux開發.Net程序的框架，降低Linux應用程序的開發成本，由于CLI（通用語言基礎設施)、C#和其他.Net的核心和基礎部分都是符合ECMA規范的，因此，在版權上應該是不會出什么問題，但是，關鍵的生產用API，比如ADO.NET、ASP.NET、Windows.Forms都是微軟私有的，因此微軟公司實際上卡住了一個核心部分，為了平息社團的爭議，微軟和Novell有一份和解協議，但是前提目標Linux平臺必須是Novell自己的，這包括社團版本的OpenSuse和Suse企業版。

　　由于社團的熱心努力，Sqlite 不但提供了跨平臺輕量級的數據庫體驗，而且，在Windows平臺下更是能與Visual Studio 完美的結合，現在Sqlite驅動的核心部分，絕大多數來源于sqlite.phxsoftware.com貢獻的代碼，那是很不可思議的工作。

　　Npsql 是.Net 下鏈接Postgresql數據庫提供者，并且也是跨平臺方案。伴隨著2.0的發布，Npgsql也是脫胎換骨，因為內置了對ASP.NET 2.0新特性的支持，這使得遷移數目眾多的Asp.Net 程序成為可能。Postgresql是一款功能強大、可擴充性極強的數據庫。特別適合作為SQL Server 的替代方案。

     基礎平臺基本完善，我們也能想象出一副Mono 平臺的戰略藍圖，但是，旅途才剛剛開始。

     Mono 平臺現在面臨諸多問題：

     開發工具的貧乏，對于小規模程序，使用Vi來編寫是再好不過的，但是對于習慣了智能感知和靈活設計環境的.Net開發這而言，這可不是能接受的事情；Mono 社團分離的Monodevelop 項目解決開發環境的問題，MonoDevelop 用起來感覺還不錯，但是，它跟Visual Studio 比起來差遠了，即使是Express版本也勝它千百倍。好在Mono的主要目標是讓Linux本地程序員向.Net 遷移，而不是Windows .Net程序員，除了Eclipse 他們也沒再見到更多的優秀IDE，其實Eclipse也一般優秀。現在MonoDevelop正處于第二個Alpha版本，還要經歷beta1和beta2，beta2不再增加新的功能，而是致力于Bug 修復，官方的路線圖說在3月末會和Mono 2.4一同發布。現在我正在使用Alpha 版本，感覺不是很好，經驗高所我，最終版會比預期的好的多，期待Monodevelop 2.0的發布，我還準備設計我的插件呢：）

　　數據庫的問題也很嚴重，Sqlite 在迅速發展，并且缺乏統一管理，因此，不能確定以后的發展狀況，版本二和現在的版本三就不兼容的，缺乏類型，事件處理麻煩，數據庫本身也需要改進。PostgreSQL雖然身出名門，但是性能、可靠性和穩定性還無法達到我們的要求。

　　Mono平臺難以應對以設計為中心的開發，因為工具的匱乏和缺乏集成協作的能力，所以，一種可能的方案是，在Windows上設計和開發，在Suse企業版上運行。這難以滿足設計師和架構師的要求。

　　缺乏成功的案例，雖然Mono展現了大量的案例，但是這些案例要么處于Novell 自己之手，要么是程序自己本身具有兼容性，而軟件生產這從來都沒有準備銷售Mono版本。.Net 展現優勢的一個重要方面是.Net提供了很多很酷的搜索功能，以Lucene.Net作為引擎，極大改善了Linux的搜索體驗。這些都需要跟多的努力，尤其需要一個好的生態圈。

     不要灰心，展望一下Mono為我們創造的無限潛能和優勢：

　　觀察分析.Net 2.0 、.Net 3.0、 .Net 3.5 以及未來的.Net 4.0， 我們發現，2.0 之前微軟關注的基礎平臺建設，但是之后，微軟的設計更加側重目標用戶而僅僅是自己。并且后續版本都建立在.Net 2.0 之上。4.0似乎要有大的改進，應該還是擴展多一些吧，最近正在研讀各個開發組的博客。由于.Net 平臺是二進制兼容、自解釋的組件方案，這比以Com為中心的二進制兼容標準要好的多，更簡便，可移植性更強，由于通過CodePlex可以更多了解官方軟件的源代碼，即使不完全相同，這也大大降低了Mono平臺的擴展和追趕微軟進度的難度。露骨的說吧，就是可以把代碼拿來，編譯后部署，不用從頭實現了。看看Mono官方的路線圖我們可以發現，Mono平臺的預期開發速度非常快，要在2009年底在部分項目上追上微軟的進度，主要是C# 4.0，發布Mono 3.0 。如果Mono 多少年后被認為是成功的話，那么MONO 3.0才是它輝煌的開端。

　　由于 Unix 族操作系統所使用X-Windows 圖形架構和微軟Windows相差甚遠，或者說實際上是一樣的，只是側重點和角度不同罷了。X-Windows是C/S模式，可以在網絡上運行。而微軟的Windows圖形架構是內置在系統里的，很多人認為微軟的Windows(Windows子系統)和X-Windows是完全不同的，這十是一個為大眾普遍認同，但是即使錯誤的觀點，Microsft Windows NT 族的系統使用的是C/S架構的微內核結構，系統內部是基于C/S設計的，不可思議吧。只有Windows能夠進行清楚的分層并且支持數目大的擴展點。這些優勢是由以下設計或者功能配合提供的：微內核設計、注冊表組件、服務框架還有大名鼎鼎的COM。微軟公司能夠存活到現在，COM是功不可沒的，微軟公司從來都不自己承擔所有風險，因為COM這個二進制兼容接口為程序提供了兼容性、可靠性和可擴展性的基礎支持，微軟有大量的客戶群 ，那也是它的盾牌。很多.Net 程序員聽到COM時，只記得一個詞，那就是“地獄”，世上本無地獄，微軟進化了，昨天就成了地獄，看不見的部分，包裝的部分就成了地獄。現在，Windows繼承平臺依然依靠COM支持，COM創造了性能和兼容性的奇跡，但是，COM依賴于C++，C++這門語言真是讓人又愛又恨，有時你愛的要死，驚嘆她的強大，還有一半的時間，你在學習，研讀標準，剖析宏和模板的用法，另外一些時間，你死的想法都有了，嘿嘿:)。微軟的Native 開發只有跟C++配合才夠酷、才無敵，但是大量的宏技巧和模板用法，有時讓人他頭暈目眩。好在COM、MFC、ATL實際上并不像傳說中的那么夸張，只是因為用的人少，或者是因為高手都不屑出來討論了，要么是秘密項目不能拿出來說，反正是沒有氛圍，學起來困難一些，所以，有諸多誤解。注冊表，很多時候，都被人指責為弊端，這通常都是Linux愛好者，提供集中的信息交流機構是復雜系統的基本要求，linux一直提供基于配置文件的方案，看看這些年Linux陣營的變化，看Linux平臺中大量增加的軟件總線框架，我們就會明白，Linux是多么希望自己是微內核機構呀。從應用角度來講，注冊表對Mono的影響不大，因為.Net旨在提供二進制兼容自解釋的組建模型，因此可以不依賴像注冊表這樣的機制。當然，Microsfot.Net在深層是絕對依賴于COM和注冊表的。這里說的有點遠了，跟Mono 聯系起來就是許多跟COM相關的部分，Mono不是做的不夠好、要么就是根本沒機會做。應為圖形框架層次布局的原因，在Linux上實現WPF有些困難，這需要更多的底層直接支持。至于WF，Mono好像也沒有實現的打算。WCF是SOA的重心，自然是少不了，只是直到Mono2.0，Mono平臺的基礎設施建設才告一段落，WCF似乎起步的較晚，重要的是CodePlex沒有WCF的源代碼，哈哈。

　　C# 2.0、3.0/3.5帶來的巨大變革，讓人激動不已，這次Mono準備在Mono3.0發布時，支持C#4.0的部分特性，這是很令人欣慰的事情了。很多事情，不是Mono的錯，Mono的局限大多有Windows和Linux差異造成的。永遠記住Windows中COM是靈魂，但是Linux做的不夠好；Linux是松散耦合，追求高性能的系統，而Windows是強耦合，基于模型的現代化系統。在Windows中，建一座小屋都會有精心準備的地基，但是在Linux下，通常就是論事的準備基礎設施和框架，但是Linux今天可不僅僅想做網絡服務器了，昨天的局限釀成了今天的哭過。Unix族系統的靈魂是通過C語言體現的，而Windows的靈魂是同過C++體現的。重復一遍，不管在哪一個系統下，COM通常都不會直接影響你的工作，但是想了解.Net了解Windows必須從Com開始。想要真正了解Mono的局限性，同樣必須從Com做起。

     關于Office,在辦公方式還沒有完全搬到網頁里之前，Office 軟件對我們依然至關重要，對微軟更重要，C#中動態的靈魂包括三部分：Office互操作的動態感知，通過動態語言運行時與動態語言交互和語言本身的動態支持。第一個方面，又是COM，在Windows平臺中 COM、C++、統一的對象模型這些都工作很好很自然，但是在Linux中，Start Office 和 Open Office 提供Com功能只能依靠模擬來實現，因為Linux沒有類似于COM的機構，這樣，提供 VSTO這種優秀的方案就很困難，問題不在Office 不在Mono，問題是缺乏中介機構，Linux系統自身所能提供支持遠達不到Com的這種高度。Linux、Office(linux平臺)、MONO都做了自己該做的事情，只是缺乏原始整體的規劃，這是歷史問題了。結果就是 C# 的需多特性不可能在Mono上展現，因為沒有基礎；C#是一個靜態語言，不要被表面絢麗所迷惑，心里要明白，在內部C#是靜態語言，動態效果依賴于功能強大的編譯器支持（我的研究方向），那是強大的可怕的支持，至少我自己實現起來挺困難，嘿嘿。和動態語言的交互依賴于動態語言運行時和編譯器的支持，或許回家看看編譯原理，要么等我的課程:)

      還有SilverLight，差點就忘了，Monolight負責完成SilverLight在Linux中使命，現在第一個版本已經發布，感覺非常酷。第二個版本發布的話， SilverLight在Linux平臺上的兼容性就會大幅提高。 

　　第一次亂彈琴到此結束，希望大家喜歡探索Mono,喜歡探索他的底層實現。