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。虽然有些人对此持怀疑态度，但理论上总是有可能的。