随笔-8  评论-196  文章-0 

聊一聊MONO的前前后后、里里外外

        Mono 2.0 是一个里程碑版本,为Linux.Net程序开发创造了基本框架。不考虑稳定性和可靠性,从功能上考虑,Mono 2.0Microsoft 兼容的API有了大幅的改进,ADO.NETASP.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 数据库战略一等公民的权利,看看.NetVisual Foxpro的支持就知道了,Access 完全是一等公民,应对中低端的数据方案需求,至少从开发环境的支持上看是这样的。

        看看Mono平台,Mono 现在数据库平台的方案部署跟Sun公司当年的差不多,广泛使用开源的数据库和驱动提供者,我觉的Mono平台对自己数据库方案的定位也是很明显的。在低端使用SQLite数据库,这是一个性能优秀,定位明确,并且广泛使用的数据库,在高端使用Postgresql数据库。.Net平台的战略规划是微软做的,因此Novell 必须找到一款能够替代Sql Server 的数据库,否则Novell 必须依赖Sql Server,那么Mono开源和低成本的招牌就说不过去。

  在这里插上一段,首先,MonoNovell公司的一个项目,旨在提供Linux平台开发.Net程序的框架,降低Linux应用程序的开发成本,由于CLI(通用语言基础设施)C#和其他.Net的核心和基础部分都是符合ECMA规范的,因此,在版权上应该是不会出什么问题,但是,关键的生产用API,比如ADO.NETASP.NETWindows.Forms都是微软私有的,因此微软公司实际上卡住了一个核心部分,为了平息社团的争议,微软和Novell有一份和解协议,但是前提是:目标Linux平台必须是Novell自己的,这包括社团版本的OpenSuseSuse 企业版。

  由于社团的热心努力,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版本,还要经历beta1beta2beta2不再增加新的功能,而是致力于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-WindowsC/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++配合才够酷、才无敌,但是大量的宏技巧和模板用法,有时让人头晕目眩。好在COMMFCATL实际上并不像传说中的那么夸张,只是因为用的人少,或者是因为高手都不屑出来讨论了,反正是没有氛围,学起来困难一些,所以,有诸多误解。注册表,很多时候,都被人指责为弊端,这通常都是Linux爱好者,提供集中的信息交流机构是复杂系统的基本要求,linux一直提供基于配置文件的方案,看看这些年Linux阵营的变化,看Linux平台中大量增加的软件总线框架,我们就会明白,Linux是多么希望自己也能有一个好的信息交流机构。从应用角度来讲,注册表对Mono的影响不大,因为.Net旨在提供二进制兼容自解释的组建模型,因此可以不依赖像注册表这样机构。当然,Microsfot.Net在深层是绝对依赖于COM和注册表的。这里说的有点远了,跟Mono 联系起来就是许多跟COM相关的部分,Mono不是做的不够好、要么就是根本没机会做或者根本不必去做。应为图形框架层次布局的原因,在Linux上实现WPF有些困难,这需要更多的底层直接支持。至于WFMono好像也没有实现的打算。WCFSOA的重心,自然是少不了,只是直到Mono2.0Mono平台的基础设施建设才告一段落,WCF似乎起步的较晚,重要的是CodePlex没有WCF的源代码,哈哈。

  C# 2.03.0/3.5带来的巨大变革,让人激动不已,这次Mono准备在Mono3.0发布时,支持C#4.0的部分特性,这是很令人欣慰的事情了。很多事情,不是Mono的错,Mono的局限大多有WindowsLinux差异造成的。永远记住WindowsCOM是灵魂,但是Linux做的不够好;Linux是松散耦合,追求高性能的系统,而Windows是强耦合,基于模型的现代化系统。在Windows中,建一座小屋都会有精心准备的地基,但是在Linux下,通常就是论事的准备基础设施和框架,但是Linux今天决不仅仅想占领网络服务器市场,昨天局限的设计酿成了今天的括苦果。Unix族系统的灵魂是通过C语言体现的,而Windows的灵魂是通过C++体现的。不管在哪一个系统下,COM通常都不会直接影响你的工作,但是想了解.Net、了解Windows必须从Com开始。想要真正了解Mono的局限性,同样必须从Com开始。

      关于Office,在办公方式还没有完全搬到网页里之前,Office 软件对我们依然至关重要,对微软更重要,C#中动态的灵魂包括三部分:Office互操作的动态感知,通过动态语言运行时与动态语言交互和语言本身的动态支持。第一个方面,又是COM,在Windows平台中 COMC++、统一的对象模型这些都工作很好很自然,但是在Linux中,Start Office Open Office 提供Com功能只能依靠模拟来实现,因为Linux没有类似于COM的机构,这样,提供 VSTO这种优秀的方案就很困难,问题不在Office 不在Mono,问题是缺乏中介机构,Linux系统自身所能提供支持远达不到Com的这种高度。LinuxOffice(linux平台)MONO都做了自己该做的事情,只是缺乏原始整体的规划,这是历史问题了。结果就是 C# 的许多特性不可能在Mono上展现,因为没有基础;C#是一个静态语言,不要被表面绚丽所迷惑,心里要明白,在内部C#是静态语言,动态效果依赖于功能强大的编译器支持(我的研究方向),那是强大的可怕的支持,至少我自己实现起来挺困难,嘿嘿。和动态语言的交互依赖于动态语言运行时和编译器的支持,或许回家看看编译原理,要么等我的课程:)

      还有SilverLight,差点就忘了,Monolight负责完成SilverLightLinux中使命,现在第一个版本已经发布,感觉非常酷。第二个版本发布的话, SilverLightLinux平台上的兼容性就会大幅提高。 

  第一次乱弹琴到此结束,希望大家喜欢探索Mono,喜欢探索它的底层实现。 

 

posted on 2009-02-07 04:11 蓝色闪光 阅读(...) 评论(...) 编辑 收藏