我的随笔

　　我也就以上观点发表下不同的意见：
　　1、作为一家商业公司，获取最大利益是他们的天性。单就看看国际上大的软件厂商，似乎谁都没有比谁就高尚到哪里去。坦白讲，如果你我能做成这样的公司，那就真是我族之幸了。
　　2、.NET 与 J2EE 的定位的确是不一样的（《再论.net纯粹性神话（中文）》一文中对于 CLR/JVM 部分有很好的对比阐述），但问题的本质不是微软不让我们跨平台了我们就不跨了，不管他的意愿是什么，从 .NET 作为标准的那天起，选择的权力就落在我们手上了！Mono 作为 .net 标准的另一种实现，只是让我们又多了一种选择，而这种选择正是我们实现 .NET 应用跨平台的最佳途径。是的，为什么要基于 .net 来开发我们的跨平台应用？因为它够好，是我认为目前最好的企业框架之一。
　　3、看看 mono 公布的开发和发布里程，你就不会再认为它只是跟随而已了，它还提供了基于 Linux 本地特性的开发集。就普通的企业应用而言，它所提供给我们的这些足以让我们实现“自由跨越”的梦想了，我们所要做的是实现之。广而概之，我们自始至终就在一路跟随，所不同的是你跟随的是Sun，他跟随的是Borland，我跟随的是Microsoft/Novell(Mono)...

　　由于 System.Enterprise、System.Drawing、System.Windows.Forms 等命名空间下的类主要是基于原生API或者COM的一种托管代码的封装，这就意味着 mono 要重新实现这样的工作是非常艰巨的，但这并不意味这是一项不可能的事，标准的伟大就在于此，它对每个人都是公平的。虽然在 1.0 版本它没有实现，但是正如 mono 网站中说明的那样，他们可能在后继版本中实现，而且还会陆续有其他的公司、组织加入进来实现其中的某些模块，一个“专制垄断”公司创立的标准却在开源社区蓬勃发展起来，这本身就是件多么有趣的事情啊！是的，mono 相对微软而言，它就像个刚参与这个游戏的初来者，我们应该为它目前所取得这样的成绩感到鼓舞和钦佩！
　　事实上微软只是提交了 CLI 的一个子集，.NET Framework 中的有些实现也并不是完全遵守该标准，mono 也同样有很多自己的扩展，譬如GTK#等，如果希望自己的 .net 应用能够顺利的运行在这两个平台中，势必要清楚了解这些细微的差异，最谨慎的做法便是不要使用那些特定的与平台相关的扩展。这点其实也是正常的，就好比遵守 J2EE 标准的各个不同的应用服务器供应商可能会有一些自己的扩展，如果你的 J2EE 应用使用了某个具体服务器产品的扩展特性，那么你的这个 J2EE 应用在移植到别的服务器产品中可能会遭遇瓶颈。微软是 .net 标准的制定者但同时也是个实现 .NET 标准的优秀产品供应商，它的产品实现做得又快又全，以致大家很容易忘记 .net 其实也是标准这么一个事实。

　　作为应用产品的设计者，我并不在意利用 System.Web.Mail.SmtpMail 发送电子邮件时，底层是调用的 CDO 的 COM 服务还是 mono 中的其他API，我只要他们能完成 System.Web.Mail.SmtpMail 接口中定义的功能即可，因为我要保证的是我应用中该功能可以顺利的运行在这两个平台中，至于其他的就不是我的职责范围了。

　　.NET Framework 库本身不是“纯粹的 .NET”，因为它使用每个机会来充分利用基础平台原语。所以，mono 的伟大之处就在于它必须要转换或者抽象出对底层服务的调用，对这个年轻的开源项目来说，我总是为此啧啧不已。

　　为了不至于跑题太远，就我认为的 .net 应用需要跨平台注意的技术项罗列如下：

1. 仔细规划和设计数据访问层
   　　使用接口设计原则来降低系统模块间的耦合度，譬如使用插件机制来实现数据访问层支持多数据库产品的运行时转移。
2. 谨慎使用特定版本或与平台相关性的功能
   　　如果你一定要使用类似 System.Enterprise 命名空间下的类，请将该部分抽象剥离出来，以便在数据访问层脱离该模块后仍然能正常提供数据访问功能，当然也就相应失去了跨数据库的事务支持等功能。
   　　不要使用平台调用服务(P/Invoke)来调用 Windows API 或者 COM/COM+ 组件。
3. 对未来的考虑
   　　关于 .NET Framework 2.0 的消息越来越多，介绍这些新组件、类库的文章也越来越多，真忍不住想把这些新酷的特性加到自己的应用中来。如果您真打算让你的应用服务继续跨平台的话，那么在实施那些冲动之举之前请先谨慎评估它们将会对您的系统在跨平台移植方面所造成的冲击。在企业应用的中间层部分，现有技术基本可以满足我们的要求，它也不像客户端那样总是对酷炫的新特性充满期待，因为它从不露脸，默默无闻的做着后台计算。
4. 多层的架构设计
   　　这个老话题就不多谈了，主要是分开界面表现层与商业逻辑层，这是保证表现层在跨平台移植时能够尽可能简单的基础。事实上我发现后期维护的很大工作量是在应对客户的个性化需求所做的界面改动，因此保证该部分的简单和独立会减少出现这种噩梦的机会。

　　以上罗列了那么多限制，不过别太担心，对一个普通的企业应用来说基本都不会突破那些限制的，想想能够在mono的帮助下把你的 .net Web Services 和您的中间层(ADO.net)组件运行在 Linux 中，后台再连接到 Unix 的 Oracle 数据库，那该是件多么酷的事情啊。不管怎么说，你总算可以轻松的对你的客户说，是的，我们的应用完全可以很好的运行在 Linux 上，而且我们从不挑剔数据库产品。至于应用成本、运行效率之类的问题，那就丢给销售人员去处理好了，我们才不关心那些充满争执的话题呢。

其他：
　　现在越来越觉得设计就是在做一种选择，在不同的方案中间取舍、选择，也是一个不断找理由说服自己，为什么这样设计的过程。因为同样一个设计需求我们总可以找出好几种不同的方案或模式，因此权衡这些模式、方案就变成了一个不断置疑又不断解决的过程，方案本身并没有对或错，除了多思考外我觉得参考 .NET Framework 的设计是个非常好的办法，这比自己乱堆设计模式中的那些模式要来得快、好，当然如果你认同 .NET Framework 是个不错的设计框架的话。在实现细节上你也可以参考它的实现方法。
　　可以通过这个网址 [http://www.aisto.com/roeder/dotnet] 去下载一个反射.net代码的工具(Reflector)，用它你就可以轻易看到 .net Framework 被反射后的 C#/VB.net/IL 源码了。当然，直接下载 mono 的源码看看也不错！