MonoDevelop 2.0 beta2终于发布了，虽然依然有BUG,翻译也很差劲，我还是决定用它做点事情,MonoDevelop 2.0 很让人期待，还记得asp.net上关于ajax的视频吧，我觉得还不错，所以我决定生产一个mono版本的的ToDo List, 或者说改造更合适一点，在这个用脑过度的时代，能省还是多省点力气吧。
    Mono 2.0 应该已经支持ajax了吧，也许是Mono 2.2, 所以问题不在于 mono 是否支持 ajax，关键在于选择什么数据源来存储数据，刚开始的时候，我想自己实现一个ObjectDataSource, 弄了半天，感觉挺复杂的。后来我觉得尽量靠近原始的实现应该更容易编写吧，我看了一下原来的 DataSet 定义 和 DataAdapter 实现，考虑自己只用实现部分就能完成任务，感觉这个主意不错，正编写的时候，我突然想：也许Visual Studio 能帮助我们实现代码，看了一下TaskDataSet的原始定义，感觉挺简洁，并且不没有强制使用Sql Server, 只是根据工厂提供者采用通用编程的方式实现代码， 我记得 Npgsql 实现了DatabaseProviderFactory, 决定让visual studio 帮助我生成代码。
    Mono 自己代的 xsd.exe 工具只能生成数据集定义，不能声称适配器类（要么是我的方法不妥当)，我在 machine.config 中的System.Data配置节添加了Npgsql的数据提供者工厂说明，并且将Npgsql.dll 和 Mono.security.dll (应该是吧) 添加到全局程序集中（仅仅添加到引用中不能用，在程序的System.Data配置节中增加说明也不能被Microsoft工具感知），然后运行自定义工具，就生成了我们需要的。cs文件，保存文件，复制到Mono项目中就好。
    转到Linux平台，使用MonoDevelop创建Asp.Net工程，增加相关的引用和文件，然后运行就好了。
附加说明：
    关于数据库：数据库使用PostgreSQL，较新的版本应该都行，大部分Linux发行版应该都能安装。数据库使用pgadmin管理，大部分 Linux发行版应该都有打包的，从系统安装源应该就能下载 PostgreSQL 和 Pgadmin, 个人建议从你所使用的linux发行版的安装源处安装这些软件（光盘或者网上的安装源），从PostgreSQL官方下载可能会遇到不必要的安装麻烦。
    关于数据库访问组件(Npgsql)：如果安装了Mono以及开发工具的话，你应该已经有Npgsql了，如果没有安装，可以安装mono-data套件（mono平台的一部分，各种数据库访问接口都有）或者直接去Npgsql官方下载。
    关于数据库创建：在SQL Server中使用[]限定一个标识符，意味着在访问是也必须严格按照定义来匹配，在PostgreSQL, ""的作用和[]类似，通常不要过分区分大小写能带来开发上的方便。特别地，我们希望自己强调大小写，但是不希望数据库系统过分拘谨于标识符的大小写，这样特别容易出错。很不幸（也许是万幸），如果你使用pgadmin创建数据库对象，默认它会自己加上强制限定符"", 我们可以在查询窗口中手动创建这些对象，华丽的工具在浏览和修改数据时还行，创建的时候，没有什么理由不使用代码完成。
     一个小程序，希望你能喜欢Mono, 一片沙漠，等你来开垦，等mono 2.0 final 发布的时候，我会给Mono Asp.Net 爱好者一份大礼，哈哈:)
     文件说明：images/* 一些图片，MasterPage.master 母板页，Default.aspx 唯一的页面，StyleSheet.css 样式表，TaskDataSet.Designer.cs 数据集和适配器定义，web.config 配置文件（其中包含针对Npgsql的System.Data配置节，应该没有用，放在machine.config供工具使用才好), App_Data/* 数据库脚本。
     表说明：tasks表，包含三个字段，taskid serial 类型，name char varing 类型，complete bool 类型。
     代码下载地址:http://files.cnblogs.com/mathphoenix/AspNetTestForBeta2.zip

     注意，程序运行环境:linux+mono+postgresql

     Have a lot of fun...

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· VC为何盯上“谷歌帮”？(2010-03-20 10:22)
· 市场预计苹果iPad初期销量无法超越iPhone(2010-03-20 10:20)
· 雅虎首席技术专家加盟风投 高管离职潮又起(2010-03-20 10:15)
· 乔布斯首谈接受肝脏移植细节 自称几乎死去(2010-03-20 10:10)
· 摩托罗拉尝试复兴 欲用社交手机实现东山再起(2010-03-20 10:07)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

      技术领域有很多让人深感困惑的地方，不管是架构师、设计师还是程序员，在完成任务之余，偶尔都有自责的地方：程序员在使用新技术完成任务的时候，有时会觉的自己旧技术都没有完全掌握，使用新技术有些好高骛远；设计师对于架构师所采用的新技术和程序员的学习成本表示担忧；架构师觉得自己可能没有完全了解技术细节，关心了客户，却忽略了程序员的感受。

      互联网充斥着各种技术，从十几岁编写第一个BASIC程序到现在，我的感受是：我从技术进步中获得生产力的提高，技术更新也带来了新的问题，在新技术的学习和使用过程中，技术创造了无限可能，很好，非常好，但是，大量的学习和试验时间，使得展示创造力的时间变得少之又少，伟大的创造只因技术学习而晚他人一步，非常可惜。刚开始学习BASIC时，我就想编写一个俄罗斯方块的游戏，那是已经确定了基本的矩阵旋转算法，但是，在老式游戏机上控制图形实在不容易，没弄成，我就编写了一个终端版的打字练习作为处女作。以后的日志里，来来回回几次，我都没有完成编写，感觉每天都在恶补各种知识，没有时间创造，终于有一次去朋友家，我们打赌我能不能在两个小时内编出俄罗斯方块，两个小时，确实没编出来，为了方便重用和面向对象，那个简单的程序用了我9个小时，从晚上10点一直到早晨8点，好在他一直都在睡觉，在他醒来时时，我说：“看，我赢了吧”，我作弊，嘿嘿。但是C语言版的俄罗斯方块，我150行左右就能搞定，功能全面。那些都是问题的缩影，更深远的影响在后面。

     没料到博客和论坛一样充满争论，技术的团队需要讨论，但是从来都不需要争论，争论反映了参与者试图确定自己正确性，而不是用来确定对最终用户是否有益，技术是用来创造产品和改善生活的，只要做到这一点，就是成功的。对产品而言，只有有市场，就能持续生产，就能建生态圈，就能发展。我们争论和讨论的核心是集中于软件的可行新和正确性的，这是正确的，但是若是过分集中于个人观点，那么对团队无益。当谈及产品观点时，有一个广泛存在的争论就是，有时，人们认为软件设计是高科技产品，不能按常规产品一概而论，软件设计会出现各种特殊因素，要特殊对待，有时，我们坐在一起闲聊时，有人不免抱怨说：“计算机太折磨人了”，很对，我完全赞同，只是，不要忘记：“你坐在电脑前就能实现梦想，过好生活，但是，其他行业可能没有这没好，不一定能这样--自己更多的决定自己的命运”

     当我讨论为准备Mono而制作产品时，人们的反映各式各样，但是对一个平台和技术永远都不要咒骂，因为，存在即道理。微软公司，是优秀的技术托拉斯，成功的商人，有着最优秀的科学家和开发人员，可否记得MFC/ATL带给你的喜悦，可否记得DirectX，很多与计算同起同休的故事，都是跟Microsoft紧密关联的，可以说对于Windows平台而言，软件设计人员的荣耀都是跟Microsoft的战略联系在一起的。微软的传奇之处在，当你看到一款产品时，你认为他是一个应用产品，但是最后，微软总能让他成为战略平台，像Office、SharePoint和Visual Studio 等等。即便在众多公司竞争愈演愈烈的今天，我从来都没有忘记windows所带了的快乐，和Windows平台所创造的可能性。世界从来都是发展的，说到底，技术也是产品。通常意义上的软件设计，是为最终用户设计产品，只要用户满意，软件就能存活；为软件设计人员设计的产品，生产者是平台销售商（像微软、SUN等等），消费者是开发人员。微软公司已经从竞争对手那里学到很多，IBM这些年依靠软件一直在不停的大把捞钱，居然放弃了自己的PC事业。对微软而言，微软公司一直从Windows销售、Office销售以及开发工具和服务等其它产品的销售赚够了钱，这些年，技术公司的收益更多的来自最终客户，这是时代的转变。Google这样的公司，取悦开发这的目的是为了更多的吸引最终客户，虽然单一客户给Google带来受益较少，但是从互联网广泛的客户和市场Google赚够了钱，不用生产信息，只需要收集、过滤和重新布局便可，这就是Google的产品，与其说Google是广告中介商，不如说Google将信息发布者变相卖给了广告商；像IBM这样的公司，关心的如何吸引大客户，如何从哪些关心事务、逻辑以及自身业务的大公司捞钱；微软关心的是如何维护生态圈，如何适应新潮流，这需要成本，并且通常只能获取间接收益，现在微软公司明显增加了最终客户的比重，更多的制作政府和企业应用软件，那是极富有前景的。过去的辉煌会积累丰富的基础，但是也成为前景的阻力。生产软件，关注客户，这就是生存之道。

      搞清楚技术工作的最终目的是什么：首先，和其他人任何行业一样，人对大的满足在于自己，因此，如果你对你的工作很满意，那么请继续；技术是为了展现你的思想，因此，如果她办不到，那么请放弃；技术是为了完成今天的任务，并且能够为明天投资，如果不能，请放弃（生存压力，请慎重）；最重要的一点，不要忘记了，技术也是一份工作，辛勤工作的目的是为了享受生活，不要忘记亲近自己家人。

      可能朋友们并不反对这些话，只是，我们都未必明白其内涵，满足自己是人办事的一个基本立足点，在团队里，首先明白这些。适当处理问题，保证项目成功，软件工厂是神奇的工厂，不管你多么细心，失败的几率还是很大，小心一点，留住客户的钱，攒给BOSS。个人满足的一个重要部分，就是学习，这是一个风险点，作为个人，会比较趋于这种方式，作为BOSS，在项目成功的前提下，绝对支持，否则，就不那么确定了。技术是为了展现我们的创造力和思想，技术人员面临的事实就是，一年12个月中，我们需要3个月来学习，不管是架构师、设计师还是程序员，谁都不能例外，否则，明天，你将找不到对自己的满足:)，时间紧迫，明白想拥有的和你能拥有的，在时间有限的情况下，你可否明白，在你的软件设计生涯中，能否设计一个自己满意的产品，或者是，你一直都在学习，不曾飞翔，对开发人员10年如一日，大量的应用、市场、规范、标准、数学学习，不管是基础学习、应用学习或者是对自己重新定位和确定新目标，时间总是最大的障碍，也许也是最大好朋友和教师，竞争是永无止境的。软件设计相关的人员不仅仅是生产者，也是消费者，我们消费的能力永远都赶不上技术公司生产的能力。完成任务很重要，为明天投资也很重要，不管怎样闲散，我相信软件设计师、程序员都像蜜蜂一样勤劳，因此，懒惰根本不是问题，问题是你如何为自己投资，你的最终目标是什么，不要忘记概率论的常识，诚然，你如果中了一百万的股彩票，生活会一下子变得非常好，你会因此变得很自在，但是你是否曾经因此就留恋股票的事情，你没有，因为你知道概率，你知道该做什么。同样，当我们学习技术的时候，技术诚然是越多越好，但是有时技术其实也像股票一般，很有魔力，但是，最终收益必然是有部分因素决定的，我们所学习的部分技术供养了我们，并且明天可能会有其他活法。时间是有限的，你必须明白如何投资，概率，找期望值最大的活法。如果忘记概率，那么，技术人员会认为所有的服务器更多的应该采用微软的，更多的技术人员都应该向微软靠拢，毕竟，微软的方案，总体拥有成本是多有多么有吸引力呀，你现在是否为你作为一名开发者感到骄傲，我相信，每个人都会，谁会忘记Windows带来的快乐呢。停下来，考虑一下，你是否发现微软所创造的可能为你创造了价值，Sure，第一批.Net书赫然写着：“微软公司为你未来十年做好了准备......"，完全没错，微软公司为自己也为生态圈做了十年准备，并且每年都有新十年。

     不要批评任何人，不要批评任何公司，关注产品，关注付你钱的那些人，有些人会让你赚更多的钱，有些人会最终付你钱，让这些事情发生，打开潘多拉魔盒的神谕就是产品，不要忘记这一点。还记得软件工程给你的提示不？可靠性处理、安全性处理、可扩展性处理、兼容性处理和用户体验处理等等，种种种种，都是以产品为核心的教义，可否记得，可否做到？如果客户没有付你钱，问题在那里？客户之所以付款，是因为客户从软件中的得到了好处，生产力提高、市场的敏捷性、资源和成本的节省，我们的软件是否帮助客户做到这一点，如果做到了，下次索取更多的回报，如果没有，退回你多拿的部分。软件是抽象和难于使用的，客户有自己的最终目标，如果他没有达到，他不会付款。同样的需求说明书，可能交付不同层次的产品，问题在哪里？如果我们为客户的未来进行了投资，软件的可维护性、可靠性，这些能否让客户接受她，我们的软件是否为客户现在进行了足够的投资，软件是否可靠，软件是否易用；如果为现在进行了投资，那么未来呢？很明显，资源是有限的，如何均衡资源，如何达到双赢，永远记住客户要什么、我们想提供什么、我们能提供什么、我们该提供什么。谁是上帝，如何投资，期待什么样的回报，付出什么样的代价，实际上得到什么。今天的合作，明天的合作。生产产品时，如果忘记概率常识，那么不可能成功。在学习中，如果忘记概率常识，那么必将疲惫而死。自己想做的，自己该做的，自己能做的，如何去做。

      从Windows DNA战略，到Windows .Net战略，到现在或者是未来的云战略，我们不可能驳斥Microsoft的道路，因为需求所产生的改变和革新是不能阻挡的，Microsoft是正确的，那只是微软，你得到了什么，你应该如何做，如何能适应微软的战略蓝图，还能做好自己的那部分。我一直觉得，如果想要理解微软的策略，我们需要从两头考虑，架构师心目中的微软方案和程序员心目中的微软技术。微软技术是根据用户需求改进的（也许是，也许不是，微软是这样说的），或者说更多的，微软是由竞争对手所提出的技术方案，确定自己应该如何改进技术战略，微软很少创造什么新思想，最后，却能将新思想表现的淋漓尽致，让她根据时代的发展演变和延续。架构师心目中的微软方案，很明显，是根据战略需要不时改进自己的技术战略，非常平滑，微软高层的视野依然很清晰，10年都就想到的，就知道的，就做到的，今天她做她该做的。也许，对技术的评价总是：表达不够优美，应用不够广泛。这是程序员视野中技术改进的源动力。至于设计师，那么就是根据两头发挥调节作用，对上提供可能性，对下保证可行性。微软公司从来都没有忘记产品，技术框架就是她们的产品。

       我看到有人为Restfull争论，因为表达方式就指责框架的优劣，有些太过火。如果微软有，用就好；没有，要么等，要么创造；尽最大努力发挥创造力，才是目标。

       看待产品，请关注时间段，拿一个已经用了十几年的方案、技术和最进几年的新实现相比，显然，老方法不够优美，然后因此说他失败的也太荒唐了，旧产品已经完成了自己的使命，曾经胜出竞争对手就是成功，今天的战争是后来者的故事。典型例子很多， COM/COM+/DCOM、内核结构，关于微软的基础架构优劣的问题总有说不完的话题，我表示中立，这些产品在历史赢得客户、软件生产商、硬件生产商的支持，取得了成功，那么她就是成功的，今天新竞争要用新产品。看待技术，我们过于偏执，忽略了驱动力，技术只是为了生产产品，技术本身就是不断改进的产品。

      除了微软之外，世界上还有很多成功的产品:gnu、apache、php、perl、linux、oracal、

firefox,safaric、ruby、python、ruby on rails、Novell等等很多，关于这些产品的争论很多，有些没有必要，对微软市场也许很有必要，但是对我们没有必要。软件设计者要足够谦逊，抬头做人，低头做事，关注产品。为争论浪费时间显然不是蜜蜂族的特征，嘿嘿:)

       我想Perl、python和ruby程序员可能都不会花时间做长时间的争论，因为他们的方案从全局看起来似乎不够完整。但是，我不认为客户会要求跟他不相关的技术部分面面俱到。迎合需求，做好自己该做的事情，发挥创造力，这就是成功的设计者，也是过的最好的人。

      在微软的平台下工作就要了解微软，微软提供了任何软件公司都不能提供巨型软件生态系统，进化的因素包括了框架和开发工具，微软的开发工具平台都会照顾到整生态圈，生态圈就是技术产品存在的理由，这是设计者有时难于把自己事情做好的原因之一，一个技术可以以不同的姿态在多个领域内完美运行，在她所提供的诸多功能之中，你是怎么学习，你如何选择，怎样才是最佳做法，如何扮演好自己的角色，这会比较费力，太多太复杂。有时候复杂的平台遮掩了表达意图的最佳方式，作为微软，必须这样做，作为个体，这有时是一个问题。技术框架带来的潜在优势，是否为你的发展铺平道路，是否帮你更多的解决今天的问题，让你享受劳动权利的同时，是否过的舒适，不要争论优劣了，请关注产品。

      微软的正确立场带来了无限的可能，但是永远不要忘记自己，不要忘记消费者身份，不要忘记自己生产的职责，否则就会流失最终客户，流失资金来源。微软的技术属于架构导向的，站在架构的高度架构，很好，很强大。如果站在架构的角度学习技术，那么，他将摧毁设计师和程序员的健康。由于架构决定最终产品，所以，微软采用架构，决定了微软产品平台的质量，也决定了最终客户所见到产品的质量。这个角度不太适合用来学习技术，因为太多太大了。作为最终的设计者必须明白这个差异，做好自己的事情，否则，问题很严重。    

程序员经常惭愧的一点就是：即使十几年前的技术，自己似乎都不够了解，这不是一个问题，现有技术是进化的产物，当你了解和学习现有技术的时候，其实你已经是在研读过去了，只是了解历史有利于更好的在现在掌握和应用它衍生物，明白她的弱点和优点，预知她的未来（不用参加PDC大会，不用看路线图，玩笑），他的未来就是为我们服务的，永远不用悔过，做好自己的事情就好。

     现在，也许应该说以前，当ruby程序员在炫耀ruby on rails 对 rest 技术的内置支持时，你会怎么想，你可能会说：“耶，很酷，太棒了”，完了，这就是你该说的全部，你只需知道微软迟早会提供Rest的支持，并且，更重要的是，确定这是否对你项目产生风险，找到方案在现在避开他，如果你抱怨微软的缓慢，那么，很抱歉，你不适合在微软的框架下工作，微软公司首先关注生产力，其次关注创造力。最早了解技术动向（特别是互联网领域），在微软社团可能有些困难，但是通常这是好事，等晚些时间，客户刚刚意识到需要这种技术时，微软已经制造出了产品级的技术，产品、文档和示例俱全，你用的时候到了。

     不管是最终产品还是技术产品，市场和用户就是存在理由。

     Mono平台提供者(Novell) 不用急急茫茫实现wpf、企业服务等等，第三方社团的产品能让她工作的很好，至少对php、本地程序员甚至是perl程序员而言，mono都能提供他们希望的社会环境(Open Source, may be partly)和技术环境(.Net, even just partly)，这就是Mono的存活理由，当然还有Suse和Novell。良臣当侍明主，选一个好的方案是很重要的，不要听信什么技术(语言)消亡，技术是活的不断改进的产品，技术的消亡只是因为支持公司的无能，无法跟进市场的需求改进方案和技术，跟微软肯定是跟对了。不要忘记自己的目标，软件设计者的梦想不应该是仅仅为了解和掌握最新的技术，而是制造优秀的软件，改善我们的生活。最终，回到键盘时，你的目标不会是要应用微软方案提供的所有功能，而是遵守够用就好的原则。没有这些新技术(更贴切的说是新的表达方式)前，我们就体验了近乎完美的产品，今天表达方式的进步，为产品创造了更多可能，不过，让你记住技术的，可能更多的是产品吧。

     Mono平台，对于Linux本地程序员很好，对那些使用perl的牛仔程序员也很好，对与php程序员也不错，在以网站为中心的中小规模应用，应该是没有问题。技术人员的一个重要特点就是推销，好不容易学到的东西，一定要用到项目中去，最终客户未必喜欢，我们要给客户需要的，不是“好”的技术，更多是产品，这更多在我们自己的修炼。当各种新思潮步入我们这个文明的国度是，你是否记得是什么技术帮他们达成心愿，论坛、博客、维客、博客、社交网络等等，你是觉得ASP.Net程序员的资源似乎太多了，充足的资源限制了创造力。微软给的太多，我们用的太少，我们满足的是学习，客户关心的是应用，我们的价值必须通过客户才能体现，这是基本的矛盾。IBM不用自己开发基础平台，它使用自己的数据库、自己的CASE工具、自己的开发工具以及社团的工具就能不断的捞钱，你是否知道原因：客户认为IBM生产了优秀的产品，这就是全部。关系数据库（也许更多)概念的提出来源于IBM，概念提出者不但获得了图灵奖，更多的，他们将数据的概念留给IBM，这就是生存至宝，IBM获得客户的信任，赢得了市场，取得了成功。回过来，当你向客户展示产品时，客户会不会仅仅因为你是ASP.NET程序员就给项目更高定位，客户只关心产品（这也包括成本）。微软创造了可能性，就展现了自己的价值，而你的价值只有通过你的产品才能实现，这就是生活。

       不管处于哪一个阶层，明白你的客户是谁、你能生产什么样的产品、客户需要什么样的产品、你应该生产什么样的产品，这才是软件公司的生存之道，也是软件设计者的生存之道。

       如果你选择了Mono那么，你必然加倍努力，你应该了解更多。并且从Windows .Net 到 Mono .Net 成本是高昂的，除非能够生产更好的产品，满足你的利益取向，否则，Mono并不适合你。或许，你应该花更多的时间在.Net上，只需要更加努力并且关注产品即可。

评论: 39　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· VC为何盯上“谷歌帮”？(2010-03-20 10:22)
· 市场预计苹果iPad初期销量无法超越iPhone(2010-03-20 10:20)
· 雅虎首席技术专家加盟风投 高管离职潮又起(2010-03-20 10:15)
· 乔布斯首谈接受肝脏移植细节 自称几乎死去(2010-03-20 10:10)
· 摩托罗拉尝试复兴 欲用社交手机实现东山再起(2010-03-20 10:07)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

　  对于Linux，我个人不偏不倚，为了使用Mono环境，方便安装、升级以及使用第三方软件，推荐使用OpenSuse。
    Linux的安装这里就不说了，提醒一下，如果条件允许，建议把镜像刻成盘光盘安装，不推荐使用硬盘安装，至于分区，建议在安装前在Windows系统中分好区，并且把Suse要用的那个分区删除掉（用磁盘管理器－－Disk.Msc)，注意不是格式化，这样，能最大程度降低安装风险，至于删掉的那个分区大小，推荐>15G。如果，您第一次使用Linux建议你认真参考安装说明（我指的是你能找到的教程），总得来说，Linux的安装可能不太容，特别是在第一次，最好能有人现场指导你。非常重要的一点就是：默认选项就很好，认真看提示，小心操作，记住语言选简体汉语。如果电脑够好的话，可以考虑使用虚拟机，推荐使用Virtul PC。

    祝你安装成功，你可以在系统安装过程中或完成系统安装后安装Mono组件（软件安装），在这里，我展示系统安装后的配置办法：

步骤一：(如果无法上网，省去这一步）添加Mono安装源，安装源是一组软件集合，经过规格定义，并且软件包管理系统能够通过源定义检索软件，系统自定义了基本安装源和更新安装源，基本安装源中的Mono软件也很多，只是，为了满足Mono开发的需要，建议增加MONO专有软件源，这样能足不出户的获取各种Mono工具和相关软件，很方便，Mono安装源的地址是（OpenSuse 11.0)：http://www.go-mono.com/download-stable/suse-110-i586 ,你要在 计算机菜单->YAST->软件->安装源中增加这个源就好了。在这里需要介绍一下控制中心和YAST，控制中心类似于Widnows中的控制面板，而YAST是Suse的MMC，各种管理工具都通过她集成，你需要借助YAST的管理工具完成系统管理任务，因此，如果和个人设置相关，控制中心是起点，如果和系统管理相关，YAST是起点，这包括网卡和ADSL拨号网络（最好是PPOE的猫，USB的在Linux下不一定可用，如果带路有那最好，尽量进简化化设置过程，让工作不依赖于Linux，因外刚开始会很不适应）的设置。

    简单介绍一下系统管理，可以在YAST中设置网卡和宽带（PPOE），配置网卡如下图：

（图一，YAST）

（图二，网络配置）

根据实际网络环境配置即可，路由选项卡中可以设置路由器，填默认网关即可。至于全局选项，如果你不用拨号连宽带，那么选择使用NetworkManager管理，否则使用ifup管理（上帝保佑你，你最好不要是这种情况），NetworkManager只能保证系统有一个连接，比如有线网和无限网只能接通一个，当需要通过PPOE拨号的时候，由于宽带要使用以太网，因此只一个端口存活就无法使用，必须使用ifup原始控制方法（正确配置DSL后，可以在终端中执行sudo /sbin/ifup dsl0 up 来连接宽带，可能要输入root密码，下面请看宽带配置，如果你在Windows下不用设置ADSL连接，这里也不用，否则，继续看：

（DSL配置主界面）

点击添加后添加ADSL连接，根据情况选择：

（选择连接界面）

由于原始定义的提供商没有中国，需要自定以，名称不重要，以后的按需选择和填写就行了，记得选选上保存密码，点击完成结束配置工作。如果顺利的话执行选择sudo /sbin/ifup dsl0 up 输入管理员（root）密码后就能上网了，祝你好运。

    QQ和MSN聊天都可以使用，腾讯有linux版本QQ，MSN可以使用 Galaxium Messenger,如果添加了Mono安装源，那么在软件管理中应该能看见。

步骤二：安装Mono相关软件：

打开软件管理 YAST->软件管理 ，然后切换到模式视图，选择所有.Net相关软件即可，这样一个基本的环境就有了，通过软件管理我们能获得绝大多数mono软件，有了这些软件之后，我们就能开始工作了，至于开发，请参照后续教程。

步骤三 了解基本资源和环境：

    MONO SDK,Mono基本工具，最重要的要属编译器了，mcs

    MonoDevelop,Mono平台主推开发环境(运行后不准重启进Windows,不要太失望，过一段时间就好，开玩笑的，不习惯的话，重启进windows好好享受简单的操作把，如果windows 和 Suse 双系统，启动后按Esc 就可以看见操作系统列表了，选Windows确定就行）

    mono-data，数据库提供者，包括我们所说的Npgsql

    Mono Web,Web开发必须的部分，包括xsp、xsp2以及Apache模块等等。

步骤四 Postgresql 数据库：

    为了支持数据库开发，我们还需要数据库，现在回到软件管理，安装Postgresql数据库，顺便熟悉一下系统的管理流程。不要使用模式浏览了，直接搜索就行。SQLite肯定已经装上了，不用管了。

附录一：Linux文化和Suse文化：

    1. No Respone is the best Response,没有回应就是最好的回应，如果执行命令后没有提示，那么恭喜你，成功完成了。

    2. As Unix User,You must know how to use text edit first,作为unix用户你必须先学会使用文本编辑器（文本模式的vi和图形模式的gedit(Gnome平台)）。

    3. Gui is too slowly ,finish your work in terminal.图形界面太麻烦，在终端中完成任务。

    4. Want to Admin the System ,Use Yast Please .要管理系统，请使用YAST(SUSE平台).

    5. Everything is file ,and the vitual file system begin with "/",所有的东西都被抽象为对象，并且虚拟文件系统一"/"开始。 

    6. Linux 不过分依赖与文件扩展名，Linux通过探测文件内容决定操作方式

    7. Linux 大小写敏感的（这是一个重要的平台差异）

    8. Linux 的当前路径(.)不在可执行文件搜索路径中（默认情况下，在终端中输入demo.sh并不能执行当前目录下的demo.sh脚本，你需要 ./demo.sh ,"./"代表当前路径）

附录二：基础软件介绍，终端、VI/GEDIT和Windows

    要在Linux下工作，不使用终端是不行的，所谓终端是类似于Windows中命令提示符的东西，最大的好处就是你可以输入命令，然后就能看到反馈，不要忘记“没有反馈就是最好的反馈这一优雅的Unix交互方式”，跟windows不同，通常命令在成功执行后是没有提示的，这有利于命令在管道之间传递有用信息，也使得使用简单命令完成复杂操作这个设想能够实现。只要是能浏览文件的地方，点击右键就能找到终端了。

    刚开始，推荐使用Gedit编辑文本文件，这个软件和记事本类似。如果有兴趣，可以试一试vi这个命令行编辑工具，类似于DOS时代的edit,用起来很不错，因为是字符界面并且需要命令，所以，初次使用起来有些困难。适应以后，编码效率会很高。

    默认情况下，Windows分区被挂在在/windows/?下面，可以在文件管理器中直接使用，只有FATX分区支持写操作，NTFS只支持读操作。

   朋友，玩得开心点，关于开发，清参看后续教程。

评论: 11　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· VC为何盯上“谷歌帮”？(2010-03-20 10:22)
· 市场预计苹果iPad初期销量无法超越iPhone(2010-03-20 10:20)
· 雅虎首席技术专家加盟风投 高管离职潮又起(2010-03-20 10:15)
· 乔布斯首谈接受肝脏移植细节 自称几乎死去(2010-03-20 10:10)
· 摩托罗拉尝试复兴 欲用社交手机实现东山再起(2010-03-20 10:07)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

    对于同样的任务，不同的平台通常都会有自己的做法，表现的内容通常类似，这种做法对程序员的影响是很大的。同样，即使在.Net框架下工作，程序员也同样面临挑战，好在.Net平台在设计这在早期就意识到这些问题，.Net本身就提供了解决方案，只是，平台兼容的代码要么蹩脚，有么太复杂。现在就让我们以尽可能小的的代价，以尽可能优美的编码方式提升程序的兼容性。     

　　兼容性问题通常可以分为有限的场景，每一个场景中只要遵守一定的规则，就能解决问题：

　　场景一，文件系统分割符的问题，Windows使用以盘符开始的文件系统，并且使用“\”作为目录分隔符，而Unix族系统使用"/"作为文件系统的开始，并且使用"/"作为目录分隔符。

    有多种方法可以解决这个问题，第一种方法，使用软实现而不是硬实现，如果程序员使用字符串相加的方式自己组建路径这属于硬实现。分隔符不同，硬实现就不能跨平台；如果使用，System.IO.Path类的Combine方法组建目录路径，那么这属于软实现，Combile使用平台特有的分隔符组建最终路径。第二种方法，使用平台分隔符变量和String.Format函数组建最终路径，这是推荐方法，因为我觉得这样更实用，System.IO.Path.Separate 常量代表了平台独立的分隔符，比如要表示当前路径下的Data/Demo.xml，你可以这样做:System.Format("{1}{0}{2}{0}{3}",System.IO.Path.Separate，System.AppDomain.CurrentDomain.BaseDirectory,Data,"Demo.xml")。有时，这仍然会带来争议，System.IO.Path下有很多常量很有用。第三种办法最简单，只要设置设置IO_MAP=ALL环境变量（针对Linux平台)，Mono运行时根据这个变量决定是否要做跨平台眏射，必要的时候，Mono会自己将"\"替换成"/"。但是，一旦你使用了绝对路径或者路径中包含盘符，那么通常，程序仍是不可移植的。解决文件系统不兼容的几个法宝：使用相对路径、使用运行时侦测路径、使用Path.Combine方法、使用路径常量(System.IO.Path下)、以及终极法宝IO_MAP环境变量。

    场景二，换行符差异，Unix族使用"\n"作为换行符，windows使用"\r\n"作为换行符。说道这里，可能有朋友不同意，因为在Windows下，我们似乎从来也不使用"\r\n"，事实是Windows在内部使用"\r\n"，但是Windows同意"\n"语义，Windows期待我们使用"\r\n"至少记事本程序是这样的。在必要时候，Windows会自己默默的转换，这主要发生在RichTextBox控件相关的应用。因为换行符导致的任何问题，你都只需要写字板打开然后保存，问题就OK了。在处理换行符的问题上，记事本和写字板有很大的不同，写字板程序识别 回车符(ASCII=13)、换行符(ASCII=10)以及标准的"\r\n"(回车符合换行符并举),更有趣的是，如果是前两种情况，在保存的时候，系统会自动将单字符"\r"或者"\n"转化为"\r\n"。但是，对于记事本而言，记事本既不识别"\r"也不识别"\n",她只识别标准的"\r\n"，这不能说明记事本不好，实际上正好相反，记事本程序被设计成能够有效的自动甄别内容编码类型的文本处理软件，因此不管是ASCII、GB2312还是UTF8，他都能准确的认出来，但是在写字板中却常常出现乱码，有时记事本自作聪明的做法也让人很无奈，特别是记事本程序有时会在文件的第一个字节处加上特殊标记，这可是苦坏了一些命令行程序，主要是不使用Windows API存取的软件(依赖Dos接口的软件)，Javac有时也会受到它的影响。这是一个说明编码问题有时很棘手的例子，我设计了一个简单程序来表现记事本和写字板之间的不同：

using System;
susing System.IO;
namespace ConsoleHelper
{
    class Program
    {
        static void Main(string[] args)
        {
            using(FileStream demo=new FileStream("OK.txt",FileMode.Create)){
                for (int i = 0; i < 100; ++i)
                {
                    demo.WriteByte(Convert.ToByte('A'));
                    demo.WriteByte(10);//10 is Return's Ascii code ,13 is NewLine's Ascii code
                    demo.WriteByte(Convert.ToByte('B'));
                }
            }
        }
    }
}
编译程序，运行后 用记事本浏览->用写字板浏览->不修改保存->用记事本浏览

实验时先用10做一遍，然后换成13在再做一遍，你会发现很有趣。这是记事本和写字板的一个故事，还有很多，基本上都是由于编码问题或者程序善意却错误的推断导致的。

有些说远了，转回正题，对于跨平台代码的要求很简单：用软编码而不是硬编码，不要自己猜测换行符是"\r","\n"或者"\r\n"，用System.Environment.NewLine常量代替即可。

　　一点知识，希望能共同分享。

评论: 6　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· VC为何盯上“谷歌帮”？(2010-03-20 10:22)
· 市场预计苹果iPad初期销量无法超越iPhone(2010-03-20 10:20)
· 雅虎首席技术专家加盟风投 高管离职潮又起(2010-03-20 10:15)
· 乔布斯首谈接受肝脏移植细节 自称几乎死去(2010-03-20 10:10)
· 摩托罗拉尝试复兴 欲用社交手机实现东山再起(2010-03-20 10:07)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

研究PostgreSQL数据库已经有好些年了，一直没能用上。最近，我准备迁移DotNetNuke到Mono平台上去（代号MonoNuke），是重新认识PostgreSQL的时候，这关系到这个项发是否可行。对于Linux软件方案，PostgreSQL寄托着很多开发者的梦想。不管是java、php、perl、ruby或者其他的，我们知道，问题不在于使用什么样的语言，而在于采用什么样的架构和方案。数据库是应用程序及解决方案中的重要环节。信息蕴藏这大量的机遇和财富，对每一个人都很重要。就MonoNuke的设想而言，数据库也是最重要的问题之一。

      使用PostgreSQL的第一个困惑在于类型，就像学习C语言或者汇编语言一样，第一个需要阐明的概念就是类型，而PostgreSQL几乎提供了所有数据库系统中最丰富的类型（就我所知），我们知道软件里有一个很重要的法则就是2/8法则，把80%的精力放到20%重要的功能上去，而PostgreSQL不是，PostgreSQL给我的第一个感觉就是浅尝辄止。学术产品和商业产品（或者我们心目中合格的产品）最重要的差别在于可靠性，仅仅做一件事情可能20行代码就能解决问题，但是如果要把他放到商业软件中去，那么可能会扩充到80行甚至更多。这还不包括为了照顾总体模型所增加的代码代价。就我而言，我希望PostgreSQL是可靠的，如果能够做到这一点，多一些功能也无妨。但是，很不幸，在我的实验环境中，PostgreSQL for Windows 不是很稳定，这多少有些让人伤心。我知道，这种状况在Linux几乎不会出现，Linux版本的PostgreSQL很稳定，毕竟Windows 版本只是一个迁移版本，主要的代码模型是基于Unix族的。PostgreSQL有众多的类型，但是我可能不会在我的项目中使用不常用的类型，主要的问题不在于复杂和担心扩展类型的可靠行，而是我觉的数据库系统做了自己不该做的事情。数据库系统的任务应该是存储、检索和协助管理，扩展类型夹杂了太多的逻辑到其中。正确的做法应该把这些放到客户代码中去，我明白数据库fans们总是期待能够改进我们的模型，并且热衷于加入更多的功能，现在处理这种关系很复杂，相信这也很难为PostgreSQL的项目管理小组：一方面，对学术而言，重要任务和价值取向是发现理论和探索可行性，而不是尽最大努力让系统变得可靠。因此，对于研究者而言，特别是不侧重与商业应用的人而言，改进系统有时就像令人乏味的重复活，我很理解这种感情。但是这正是我们系统所遇到的问题，不管将系统是推销给谁，总是期待能够帮助他人达到目的，如果系统是不可靠的或者说是低效的，那么通常这会伤害别人对软件的信任，在这里就是失去对PostgreSQL的信任。伯克利分校的数据库研究很有趣，通过研究相关的理论我们能发现学术的神奇之处，如果准备研究这个数据库系统，建议准备英语字典、数学字典和打印机；另一方面，对许多志愿者而言，志愿者倾向做创新的工作以展现自己的价值，让系统少死两次机并不会引起其他人的注意，相反增加新的模块和功能可能更符合他们的要求；还有，对于开源软件而言，更重要的是维护整个社团的和谐发展和生态圈。因此，这通常意味着不容易进行架构上的改进，关系数据库的技术已经处于稳定状态，研究者通常并不指望在这一领域能有惊天的作为，而会更加关注应用方面，因此底层的数据库研究者数量就会降低，这对PostgreSQL这中纯开源数据库而言，有些不利。

        影响PostgreSQL发展的第二个问题在于，PostgreSQL采用了进程模型，问题不在于进程模型和线程模型之间的差异，在于windows族和Unix族操作系统对于进程和线程处理的差异，对于进程模型，很多人都是直接的给予批评，从某种程度上而言，这是由于误解导致的：在现代的计算机科学教育中，我们对于进程和线程的第一个认识就是，进程是操作系统分配资源的单位，线程是运行的单位，再程序设计时，应该优先考虑采用线程模型而不是进程模型。利益主体决定模型取向，对于程序而言，增加一个新进程将会额外分配新的资源，显然者要比在父进程中启动一个线程能占有更多的资源，如果启动一个线程，那么她会分享进程的资源；如果让操作系统决定，系统可能更倾向于使用线程。由于系统设计的不同，影响了进程和线程的使用：

首先，因为资源分配的问题，启动进程是需要时间的，特别是在windows平台下，这能有效的防止蠕虫类程序的泛滥（应该只能能起一定的作用）；

对于线程，不同的系统实现方法是不同的，对于Windows而言，所有的线程都是内核线程，系统统一处理线程的问题，并且，这跟系统的消息机制也有关系，影响了windows的性能（有时是正面，有时是负面的）。而对于Unix族而言，系统在用户库层面上实现线程库，这影响了系统对对线程优势的发掘；由于历史的原因，Unix族平台程序喜欢使用进程模型，并且表现的也很好，Apache 服务器就是一个例子，Unix平台更像是一个专用平台，所以他关注的是把一件事情做好，因此相对于线程所带来的优势，服务器系统更喜欢核心部分占有更多的资源，进程模型是一个好方法。

影响进程和线程的另一个问题在于系统的资源模型，由于Unix族系统是一个弱模型的系统，系统通过抽象文件接口，把资源抽象到文件接口层面。由于系统相对较简单，没有复杂的模型和过多的层次，因此进程间通信的效率相对较高，方法也较多。而对于windows而言，windows系统是基于模型的系统。系统有明确的模型和分层，因此进程间通信的代价较高，并且使用资源的代价也较高，这就导致进程模型很不适合windows系统。对于PostgreSQL而言，这带来的直接问题就是，PostgreSQL应该针对平台重新设计，这对志愿者社区而言，很明显，成本太高，不太可能。维护两份代码基成本是很可怕的，这导致了PostgreSQL在Windows平台所遇到的问题。社团已经做了很大的努力改进 PostgreSQL在 windows平台下的表现，特别是新版的PostgreSQL使用Visual C++ 2005完成编译工作，这很大程度上改进了系统的性能，Visual C++ 编译器的表现是一直比较不错，我认为。问题在于，如果不能改进模型，那么问题将始终无法得到解决。就我们的方案而言，这个问题并没有实质性的影响，因为我们的系统本来就是定位在Linux平台上运行的，了解一下PostgreSQL对于未来使用它应该是一种优势。

       PostgreSQL将扮演Mono平台战略中SQL Server 的角色，了解它是我们前进的有力助手。

       希望关于进程和线程的讨论不要引发战争。

评论: 8　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· VC为何盯上“谷歌帮”？(2010-03-20 10:22)
· 市场预计苹果iPad初期销量无法超越iPhone(2010-03-20 10:20)
· 雅虎首席技术专家加盟风投 高管离职潮又起(2010-03-20 10:15)
· 乔布斯首谈接受肝脏移植细节 自称几乎死去(2010-03-20 10:10)
· 摩托罗拉尝试复兴 欲用社交手机实现东山再起(2010-03-20 10:07)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

在Mono平台开发前应该做的第一个事情就是，调整好心情，降低期望值：

    对于Linux本地C程序员而言，由于习惯了疯狂和有魔力的本地C程序员开发，因此对于Mono提供的诸多限制可能不太满意。大体而言，Mono和.Net程序一样，属于框架开发的范畴，对于框架开发，最好在框架规定的范围能工作，否则会陷入孤立无缘的境地。Mono没有C开发那些唾手可得的工具，也不能对系统进行无限的挖掘，Mono关注的是应用软件开发，不是系统软件（Mono 可以支持本地服务开发）。Mono支持两种类型软件开发，以WEB为中心的软件和以本地为中心的开发。WEB包括常规定义上的应用型网站开发，也包括基于服务的模型开发。由于服务现在成为软件开发的中心并且迅速进化。作为.Net替代平台，Mono显得很混乱，主要因为.Net以服务为中心的设计在Mono 上还无法完全施展，因为Mono基础平台正处于2.x阶段，等09年底应该是一个新阶段。对于本地程序开发，主要包括一GTK#和System.Windows为中心的图形界面程序开发，还包括服务软件的开发(linux service机构)，也包括一Lucene.Net为基础的搜索软件的开发。

    对于Windows .Net 程序员而言，首先要极度降低期望值，Mono没有绚丽的工具，缺乏足够的第三方软件，并且工具之间的集成也做得不太好，代码编写可能不很流畅，MonoDevelop也可能让你很失望，这些都是Windows上廉价的.Net开发工具把我们惯坏了。Windows.Net程序员来到Mono的主要原因有很多，可能是因为好奇，希望迁移自己的程序，想窥探一下Mono实现以确定和自己想的差距有多远，更多的是要学习。就像把孩子放到艰苦的地方锻炼一样，来到Mono，你将会有同样的感觉，非常的贫瘠。Mono工具还比较原始，文档也比较少，我觉得这方倒是学习的好地方，每一次当我打开MSDN，我都会望书惊叹，多么希望积累足够丰富的Windows知识呀，但是MSDN让人感到很大很茫然，最后，还是购买专著研究更合适，其他要用的,用的时候在查资料吧。在Mono平台上资料非常少，这也是优势，对于C#语言本身而言，那是学习的好地方，就像C++一样，C#本身是一个迷人的语言值得研读一下，但是C#上紧紧捆绑的应用更适合生产而不是学习，如果要学习，需要找一个单调一点、产品单一的环境，当然学好了赶紧回来，赶紧拥抱Windows:)

了解平台之间的差距：

    关于文件系统，Linux基于虚拟文件系统，这是Linux最成功的设计之一，表面看起来就是，任何文件和资源都可以通过一"/"开始的文件来访问，文件之间的分割符是"/"。在Windows中，文件系统经过多次抽象，看起来类似与以“C:”、“D:”这样的方式开始，并且文件之间的分隔符使用"\"，这是很多程序不可移植的重要原因，可以参考后来的文章，了解如何提高程序的可移植性。

    第二个差距就是换行符的不同，在Windows平台，一个换行符意味着“\r\n",由于在字符终端时代，"\n"的任务是使光标处于下一行的同等位置，而"\r"则是使光标处于一行的开头，因此，去下一行开始则意味着要配合使用两个控制符；在Unix族平台，换行符则使用"\n"表示，这是历史原因，我猜想是由于早期终端规范导致的。

    关于Unicode，这现在应该不成问题了，现在Linux多都在内部使用了Unicode，以前Linux在内部使用ASCII编码及其扩展。由于Windows在内部使用Unicode已经很长时将了，.Net 的Unicode 支持非常好，Char字符本省就是Unicode的，并且System.Text也为文本处理提供了诸多支持。虽然Mono实现了.Net的功能，但是我发现，系统对Unicode 的处理不够细心，一个细心设计的类库和平台，应该保证在大部分情况下系统的反应能和程序员预期的一样好，但是Mono没有做到，那是以前的事情了，由于Mono RunTime在一直改进，现在应该有大幅进步吧。文本处理一直都是计算机科学的基本问题之一，通常情况下，处理多国编码的最简的办法是使用UTF-8，由于历史原因，许多接口并没有使用UTF-8,而是使用蹩脚的转换。在Windows下，在.Net出现之前，文本处理一直很让人头疼，赞扬.Net时常提的一个问题就是：“难道你还想执行字符串转换工作？”，看看char *、wchar_t*、_bstr_t、CComBSTR、CString、basic_string 和System.String，往事不堪回首呀，如果不跨库，不跨方案，那么字符串处理还算轻松，一旦要跨库跨平台跨方案，那么，字符串处理就是程序员的噩梦。

    结构差距，Microsoft.Net 是一个旨在建立巨大生态圈的大方案，希望面面俱到。因为Microsoft企业平台架构，Microsoft.Net能够更好的跟Windows的业务核心和系统核心无缝集成，在Microsoft.Net上，架构师、设计师和程序员看到的不仅仅是.Net，还包括大量运行的关系业务前途的企业服务和组件。在Mono上，由于需要依赖第三方实现，依赖大量的绑定来使用系统或其他软件的功能，有时侯透明度不够。没有MMC、域、MSMQ、WMI、事务支持、服务架构、数据库服务等重要基础结构的支持，这些都是在开发早期就应该确定的因素，请确定Mono能够满足你的要求。另一方面，这些在很多时候也是一个优势，有大量的第三方组建在实现这些功能，包括Apache、Mozilla、Postgrsql等等社团。

评论: 13　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· VC为何盯上“谷歌帮”？(2010-03-20 10:22)
· 市场预计苹果iPad初期销量无法超越iPhone(2010-03-20 10:20)
· 雅虎首席技术专家加盟风投 高管离职潮又起(2010-03-20 10:15)
· 乔布斯首谈接受肝脏移植细节 自称几乎死去(2010-03-20 10:10)
· 摩托罗拉尝试复兴 欲用社交手机实现东山再起(2010-03-20 10:07)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

        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，喜欢探索它的底层实现。 

评论: 42　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· VC为何盯上“谷歌帮”？(2010-03-20 10:22)
· 市场预计苹果iPad初期销量无法超越iPhone(2010-03-20 10:20)
· 雅虎首席技术专家加盟风投 高管离职潮又起(2010-03-20 10:15)
· 乔布斯首谈接受肝脏移植细节 自称几乎死去(2010-03-20 10:10)
· 摩托罗拉尝试复兴 欲用社交手机实现东山再起(2010-03-20 10:07)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库