聊一聊MONO的前前后后、里里外外
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。现在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，喜欢探索它的底层实现。
