WindowsDNA与.net

80酷酷网    80kuku.com

  window可复用软件不是一个新概念。八年来,人们一直在使用各种形式的组件对象模型(COM)。事实证明,它是最为成功的可复用软件模型。COM引进了“组件”的概念——它是可复用的代码块,可以将多个独立函数的功能进行组合,从而扩充成诸如Microsoft Word这样的应用程序。

大多数开发人员使用OLE时深刻体验了COM功能。OLE是基于COM形成的一组功能,使得用户能将一种文档嵌入到另一种文档中。这个功能本身似乎不太引人入胜,但它的作用却不同凡响:当用户将一个Excel文档粘贴到Word文档中后,单击嵌入的Excel文档时,OLE将会把Word的工具栏和菜单转换成Excel的工具栏和菜单。



在95 年之前,当互联网兴起并如火似荼的时候,比尔.盖茨却认为网络应用并不是未来软件开发的方向。在当年的互联网四骑士(思科、AOL、SUN、网景)里面,人们看不到微软的影子。但网景的成功很快惊醒了微软,微软开始奋起直追,并凭借强大的实力很快从第一代互联网的追赶者变为第二代、第三代互联网的领先者。但这似乎并不足以满足微软的胃口,微软耗费重金打造的.NET 要成为下一代互联网的标准。
我们看一下遵从Windows DNA体系的WEB应用的缺陷。遵从Windows DNA体系的COM/DCOM/COM+分布式应用可以将程序功能分布到整个网络上,DCOM构造于RPC 体系结构的最顶层,使用DCOM远比使用RPC 容易的
多,但是它仍然继承了RPC的一些缺陷。第一个缺陷就是:RPC和DCOM都更适用于Intranet 而不是Internet。RPC和DCOM要求的端口在防火墙内部,不太可能被打开。这种局限对于开发上线的WEB应用是一个很严重的问题。第二个缺陷是使用COM/DCOM需要注册或者发布,这会对应用程序产生很大的影响,所以它并不是一个理想的解决方案。这两个缺陷.NET 都可以利用Internet上的标准XML、SOAP 来解决。第三个缺陷就是利用ASP开发WEB应用时,会将负责程序的脚本和HTML混杂在一起,导致页面的脚本语言结构十分复杂,逻辑不清晰,可读性差不仅给编程人员本身带来不便,也给系统的维护带来不小的困难,特别是当应用逻辑需求发生变动时,修改这些臃肿、晦涩的解释性脚本源代码真是味同嚼蜡。.NET 中的ASP.NET 可以使代码和界面完全分离,并提供了基于组件的开发,是WEB 应用的开发效率大为提高。第四个缺陷是COM/DCOM 是平台相关的,只能基于WINDOWS 平台。这让许多应用只能选择J2EE体系。微软的.NET 有望解决这个痼疾。有消息说,微软2003年将推出基于LINUX平台的.NET FRAMWORK。虽然有些人对此持怀疑态度,但理论上总是有可能的。

分享到
  • 微信分享
  • 新浪微博
  • QQ好友
  • QQ空间
点击: