Com/Dcom/Com+的思考
从 COM(Component Object Model) 时代到 DCOM(Distributed COM) ，微软扮演了一个推动者的角色。如果说 COM 提供了一个 Windows 平台上的对象通讯技术，并且逐渐成为应用程序之间彼此通讯及互动的技术主流，那么 DCOM 则是解决了计算机的通信和互动技术。
COM 的着眼点是在于同一台计算机上不同应用程序之间的通讯需求，跨到另外一台计算机之外，就不是一开始 COM 所设想到的领域。所幸跨程序的通讯和跨计算机的通讯差异仅在于通讯协议的处理 ( 也就是定位问题 ) ，对于数据交换上型别差异的处理并不会因此而有区别。所以要让 COM 的环境能更进一步延伸到跨计算机的领域，只要妥善解决计算机定位的需求，就有机会克服。同样幸运的是， COM 在一开始的设计中完全不去碰触跨计算机的问题，使得要在 COM 的架构之上再架上一层跨计算机的处理环境并不会去破坏到原本的架构。于是 COM 的网络延伸版本 DCOM(Distributed COM) 就此出现，专责让 COM 组件可以在网络环境下持续提供服务。 DCOM 最主要处理的是两个议题，第一个议题是网络通讯能力，第二个议题则是权限的问题。之前 COM 是在同一台计算机中找特定的组件，而 DCOM 则要更进一步去找网络上的某台计算机，之后沿用 COM 的机制找到计算机上的组件。
到了 .NET 当中，跨计算机的问题同样也需要对应的技术进行处理， .NET Remoting 就是一个对应于 DCOM 的技术，它让存活在不同应用程序域 (AppDomain ，一个 .NET 中的新概念 ) 、不同执行程序、以及不同计算机上的对象能够顺畅的进行沟通协作。在累积了长期以来分布式应用的经验之后，微软没有理由把东西设计的更难用。从某种意义来说， .NET Remoting 提供了比过去更易于使用的开发架构，用来来支持跨计算机的沟通作业，省却开发人员建立分布式应用程序时必须花费的心力，不过这样一个“出色”的分布式应用应用框架并没有得到本来应该得到的“待遇”。相对于 Java 的 RMI 而言，它更加简单同时保持设计方面的弹性，同时摈弃了 DCOM 的一些缺点，在对于一个前后端必须以有状态紧密结合方式进行互动作业，同时又期望呼叫和数据交换的动作上能以最有效的方式进行的环境而言， .NET Remoting 是一个比较恰当的选择方案。
可是问题在于微软本身对于 XML Web Services 的狂热推崇让 .NET Remoting 迷失了本来属于它自己的阵地，也就是说 XML Web Services 的过火让 .NET Remoting 忘记了自己应该承担的角色，于是在开发者眼中成为了一个“可有可无”的作品，至少对于很多开发人员而言，在需要创建分布式应用程序的时候首先考虑的是 XML Web Services ，而在于企业内部应用，特别是在可以控制服务器和客户端平台的情况下（比如完全基于 .NET 平台的应用）， Web Service 因为效率等等各个方面的原因并无法体现出优势。从技术本身来讲， .NET Remoting 是一个非常出色的架构，但在商业方面，这是一个失败，毕竟，设计一个出色的产品然后束之高阁难免“不像话”。
.NET Remoting 恰恰是这个战略的牺牲品，虽然拥有与生俱来的优点，不过依然生不逢时。
Enterprise Services
从一个很直接的感觉来说， Enterprise Services 只是对于 COM+ 的一个包装，从使用方式和技术实现本身而言，和 VB 或者 VC 下使用 COM+ 服务没有本质的区别，而更多的只是在于多了一层托管代码的包装，让 .NET 开发人员能够比较顺利的使用这些服务的功能。
相对于 J2EE 平台上的应用服务器如 BEA 的 WebLogic ， IBM 的 WebSphere 或者开放源代码的 JBoss ，微软是希望能够在企业级应用之中分一杯羹，可是因为先天不足的原因，在企业应用中需要的事务、负载平衡、故障转移等等技术中的表现不是那么尽如人意，至少缺乏非常清晰的应用服务器（ Application Server ）的概念，虽然微软不止一次的强调操作系统本身就是一个应用服务器，一个 IT 信息的基础结构。但是从开发人员实际的使用来看，这是一个“晦涩难懂”的产品。
虽然 .NET Framework 改变了很多东西，但是作为企业级应用中最重要的支撑技术——事务和服务，并没有得到同等程度的发展，我想这个也就是很多大型企业应用目前不选择 .NET 的一个理由吧，毕竟从 MTS —— COM+ —— Enterprise Services ，这一路走来微软始终不是提供一个非常透明的机制让开发人员去控制各个环节（可能和微软一贯以来的策略有关，只是关心最广泛的应用而不是最高端的应用），而 .NET 中的所谓企业服务，和竞争对手提供的相当的 EJB 还是有比较大的差距，这是一个日前的微软无法解决的软肋。
Web Service
从一开始，微软就将其作为“重头戏”推出，并且饶有意思的增加了 XML ，然后那个“ XML Web Services ”就成为了 .NET 战略中一个非常重要的术语，就如微软的白皮书所言“ Microsoft? .NET 是 Microsoft XML Web Services 平台”，微软通过 .NET 来改变现有的互联网络结构，“ Windows 正在走向过去”这样的宣传是在于希望各个子系统之间的通信完全基于 Web Service ，那样的话，作为 Win32 开发人员一直困扰的组建注册，分发等等一系列问题都能够得到解决，并且能够用更多的语言更多的平台去开发应用。
“一切皆是 Web Service ”，这是一个冒进的举动，至少对于 4 年以前的世界，而这四年以来，虽然 Web Service 有很多很多的优点可以让我们“歌功颂德”，但是不是“万金油”，比如一直称垢的性能和安全问题也阻碍了 Web Service 一统天下，于是其他分布式应用架构在特定的领域依然能够有自己的生存空间。
这一次，微软高估了 Web Service ，虽然目前的 .NET 是实现 XML Web Services 最好的平台， Visual Studio .NET 也提供了从上至下的包装，让开发人员完全可以不关心协议的底层实现，比如 SOAP ，比如对象序列化，比如 WSDL ，因为一切的一切都可以在 IDE 中自动完成。我们不否认因为 .NET ， Web Service 从概念已经走进应用，而 WSE 2.0 的出台更加 Web Service 具备了互操作能力，不过依然无法改变开发人员的观点，只有在企业外网应用集成或者内部异种平台整合的时候才能够体现出优势，在于需要高度响应和服务支持的应用方面， Web Service 只是一个臆造的神话。
ASP.NET
我们无法否认，这项技术对于开发人员而言是一个颠覆性的改变，从静态的 HTML 到 CGI 再到 ASP/JSP/PHP 时代，我们都必须去了解 HTML ，了解 HTTP ，对于高水平的开发人员而言，需要掌握的还远远不止这个，在脚本横行的时代，我们必须很清楚的去了解实现的各个细节，包括 HTML ， JavaScript ， CSS ，还有和服务器相关的 Request 、 Response 。最直接而言，开发人员必须严格控制所有 HTML 及其相关内容的产生，脚本带来的只是一个相对于 CGI 层次更加高级的“自动化”罢了。
然后， ASP.NET 将这一切完全改变， WebForm 让 Web 开发人员能够和 Windows 开发人员一样处理页面事件，同时可以完全的访问强大的 .NET Framework 类库，而且预先编译机制解决了 ASP 一直以来的效率低下问题。而在服务器端的设计，在原先 ISAPI 的基础上从新实现了 HttpHandler 和 HttpMoudle ，从而为开发人员提供了高度扩展的可能，而日前比较成熟的 WebLog 引擎 .Text 正是这些技术的经典之作。
XML Web Services 的内置集成则使 ASP.NET 成为 Web Service 应用的最好实现，日前市场上相当大部分的 Web Service 都是基于 ASP.NET 的，在这点方面 ASP.NET 已经远远超出 Java 社群的技术，包括 JSP ，包括 Struct ，包括 JSF 还有其他相关的 Web 应用技术，在 ASP.NET 都能够得到非常好的集成。
我们不可能否认这个事实，相当大一部分（我个人认为是大部分）的开发人员转向 .NET 是因为 ASP.NET ，对于 ASP 开发人员而言， ASP.NET 提供了更加强大的功能，很多在 ASP 中必须依赖组件技术来解决的问题比如文件上传在新的平台上已经成为内置支持，当然更加重要的是依赖 Visual Stuio.NET 强大的集成开发环境能够成倍的提高生产率。而另外平台的开发人员转向 ASP.NET 我想也是因为弹性的设计及其便捷的开发，我相信没有太多人会怀疑 ASP.NET 已经走在 Web 开发的最前沿。
当然，任何事情没有绝对的完美，在 .NET Framework 1.1( 也就是 .NET 的第二个版本 ) 之前，太多的 Postback 也是让开发人员抱怨之处，而且采用 WebForm 的开发方式让很多开发人员不是那么容易的处理客户端脚本，所有的事件实现都是依赖于 ViewState ，因此在低带宽下的网络应用，不断地提交也让有些用户感到“恼火”。
这个世界没有绝对的完美，但是会一点一点走向完美，也许 ASP.NET 2.0 就有太多东西值得期待。
ADO.NET
相信大家不会忘记 ADO （ ActiveX Data Object ） , 我想 Windows 上面数据库开发流行它功不可没，通过统一的接口来实现对于数据库的访问，从而屏蔽复杂的数据库访问协议。而到了 .NET 时代， ADO.NET 进一步将数据访问“进化”，不要以为 ADO.NET 只是 ADO 的一个升级，在 ADO 的技术上提供了一个托管类库，除了都是数据访问框架，其他没有太多本质的关联。
虽然 ADO.NET 带来的震撼远远不如其他技术，可依然有很多东西值得我们去欣喜，毕竟创新总是一件好事情，何况是这个最成功的软件公司带来的创新，那么我们就来看看到底带来了什么：
1．除了提供了传统 ADO 的 Connection,Command 以外，我们意外的没有看到 Recordset 这样的对象，而是提供了 DataReader 用来处理向前滚动的数据访问，最最重要的是加入了 DataSet 这样的概念，因为如此，我们能够实现很多数据库应用中需要的“ Disconnected Application ”，能够实现“ InProc-Database ”，而这一切，通过 DataSet 能
COM 的着眼点是在于同一台计算机上不同应用程序之间的通讯需求，跨到另外一台计算机之外，就不是一开始 COM 所设想到的领域。所幸跨程序的通讯和跨计算机的通讯差异仅在于通讯协议的处理 ( 也就是定位问题 ) ，对于数据交换上型别差异的处理并不会因此而有区别。所以要让 COM 的环境能更进一步延伸到跨计算机的领域，只要妥善解决计算机定位的需求，就有机会克服。同样幸运的是， COM 在一开始的设计中完全不去碰触跨计算机的问题，使得要在 COM 的架构之上再架上一层跨计算机的处理环境并不会去破坏到原本的架构。于是 COM 的网络延伸版本 DCOM(Distributed COM) 就此出现，专责让 COM 组件可以在网络环境下持续提供服务。 DCOM 最主要处理的是两个议题，第一个议题是网络通讯能力，第二个议题则是权限的问题。之前 COM 是在同一台计算机中找特定的组件，而 DCOM 则要更进一步去找网络上的某台计算机，之后沿用 COM 的机制找到计算机上的组件。
到了 .NET 当中，跨计算机的问题同样也需要对应的技术进行处理， .NET Remoting 就是一个对应于 DCOM 的技术，它让存活在不同应用程序域 (AppDomain ，一个 .NET 中的新概念 ) 、不同执行程序、以及不同计算机上的对象能够顺畅的进行沟通协作。在累积了长期以来分布式应用的经验之后，微软没有理由把东西设计的更难用。从某种意义来说， .NET Remoting 提供了比过去更易于使用的开发架构，用来来支持跨计算机的沟通作业，省却开发人员建立分布式应用程序时必须花费的心力，不过这样一个“出色”的分布式应用应用框架并没有得到本来应该得到的“待遇”。相对于 Java 的 RMI 而言，它更加简单同时保持设计方面的弹性，同时摈弃了 DCOM 的一些缺点，在对于一个前后端必须以有状态紧密结合方式进行互动作业，同时又期望呼叫和数据交换的动作上能以最有效的方式进行的环境而言， .NET Remoting 是一个比较恰当的选择方案。
可是问题在于微软本身对于 XML Web Services 的狂热推崇让 .NET Remoting 迷失了本来属于它自己的阵地，也就是说 XML Web Services 的过火让 .NET Remoting 忘记了自己应该承担的角色，于是在开发者眼中成为了一个“可有可无”的作品，至少对于很多开发人员而言，在需要创建分布式应用程序的时候首先考虑的是 XML Web Services ，而在于企业内部应用，特别是在可以控制服务器和客户端平台的情况下（比如完全基于 .NET 平台的应用）， Web Service 因为效率等等各个方面的原因并无法体现出优势。从技术本身来讲， .NET Remoting 是一个非常出色的架构，但在商业方面，这是一个失败，毕竟，设计一个出色的产品然后束之高阁难免“不像话”。
.NET Remoting 恰恰是这个战略的牺牲品，虽然拥有与生俱来的优点，不过依然生不逢时。
Enterprise Services
从一个很直接的感觉来说， Enterprise Services 只是对于 COM+ 的一个包装，从使用方式和技术实现本身而言，和 VB 或者 VC 下使用 COM+ 服务没有本质的区别，而更多的只是在于多了一层托管代码的包装，让 .NET 开发人员能够比较顺利的使用这些服务的功能。
相对于 J2EE 平台上的应用服务器如 BEA 的 WebLogic ， IBM 的 WebSphere 或者开放源代码的 JBoss ，微软是希望能够在企业级应用之中分一杯羹，可是因为先天不足的原因，在企业应用中需要的事务、负载平衡、故障转移等等技术中的表现不是那么尽如人意，至少缺乏非常清晰的应用服务器（ Application Server ）的概念，虽然微软不止一次的强调操作系统本身就是一个应用服务器，一个 IT 信息的基础结构。但是从开发人员实际的使用来看，这是一个“晦涩难懂”的产品。
虽然 .NET Framework 改变了很多东西，但是作为企业级应用中最重要的支撑技术——事务和服务，并没有得到同等程度的发展，我想这个也就是很多大型企业应用目前不选择 .NET 的一个理由吧，毕竟从 MTS —— COM+ —— Enterprise Services ，这一路走来微软始终不是提供一个非常透明的机制让开发人员去控制各个环节（可能和微软一贯以来的策略有关，只是关心最广泛的应用而不是最高端的应用），而 .NET 中的所谓企业服务，和竞争对手提供的相当的 EJB 还是有比较大的差距，这是一个日前的微软无法解决的软肋。
Web Service
从一开始，微软就将其作为“重头戏”推出，并且饶有意思的增加了 XML ，然后那个“ XML Web Services ”就成为了 .NET 战略中一个非常重要的术语，就如微软的白皮书所言“ Microsoft? .NET 是 Microsoft XML Web Services 平台”，微软通过 .NET 来改变现有的互联网络结构，“ Windows 正在走向过去”这样的宣传是在于希望各个子系统之间的通信完全基于 Web Service ，那样的话，作为 Win32 开发人员一直困扰的组建注册，分发等等一系列问题都能够得到解决，并且能够用更多的语言更多的平台去开发应用。
“一切皆是 Web Service ”，这是一个冒进的举动，至少对于 4 年以前的世界，而这四年以来，虽然 Web Service 有很多很多的优点可以让我们“歌功颂德”，但是不是“万金油”，比如一直称垢的性能和安全问题也阻碍了 Web Service 一统天下，于是其他分布式应用架构在特定的领域依然能够有自己的生存空间。
这一次，微软高估了 Web Service ，虽然目前的 .NET 是实现 XML Web Services 最好的平台， Visual Studio .NET 也提供了从上至下的包装，让开发人员完全可以不关心协议的底层实现，比如 SOAP ，比如对象序列化，比如 WSDL ，因为一切的一切都可以在 IDE 中自动完成。我们不否认因为 .NET ， Web Service 从概念已经走进应用，而 WSE 2.0 的出台更加 Web Service 具备了互操作能力，不过依然无法改变开发人员的观点，只有在企业外网应用集成或者内部异种平台整合的时候才能够体现出优势，在于需要高度响应和服务支持的应用方面， Web Service 只是一个臆造的神话。
ASP.NET
我们无法否认，这项技术对于开发人员而言是一个颠覆性的改变，从静态的 HTML 到 CGI 再到 ASP/JSP/PHP 时代，我们都必须去了解 HTML ，了解 HTTP ，对于高水平的开发人员而言，需要掌握的还远远不止这个，在脚本横行的时代，我们必须很清楚的去了解实现的各个细节，包括 HTML ， JavaScript ， CSS ，还有和服务器相关的 Request 、 Response 。最直接而言，开发人员必须严格控制所有 HTML 及其相关内容的产生，脚本带来的只是一个相对于 CGI 层次更加高级的“自动化”罢了。
然后， ASP.NET 将这一切完全改变， WebForm 让 Web 开发人员能够和 Windows 开发人员一样处理页面事件，同时可以完全的访问强大的 .NET Framework 类库，而且预先编译机制解决了 ASP 一直以来的效率低下问题。而在服务器端的设计，在原先 ISAPI 的基础上从新实现了 HttpHandler 和 HttpMoudle ，从而为开发人员提供了高度扩展的可能，而日前比较成熟的 WebLog 引擎 .Text 正是这些技术的经典之作。
XML Web Services 的内置集成则使 ASP.NET 成为 Web Service 应用的最好实现，日前市场上相当大部分的 Web Service 都是基于 ASP.NET 的，在这点方面 ASP.NET 已经远远超出 Java 社群的技术，包括 JSP ，包括 Struct ，包括 JSF 还有其他相关的 Web 应用技术，在 ASP.NET 都能够得到非常好的集成。
我们不可能否认这个事实，相当大一部分（我个人认为是大部分）的开发人员转向 .NET 是因为 ASP.NET ，对于 ASP 开发人员而言， ASP.NET 提供了更加强大的功能，很多在 ASP 中必须依赖组件技术来解决的问题比如文件上传在新的平台上已经成为内置支持，当然更加重要的是依赖 Visual Stuio.NET 强大的集成开发环境能够成倍的提高生产率。而另外平台的开发人员转向 ASP.NET 我想也是因为弹性的设计及其便捷的开发，我相信没有太多人会怀疑 ASP.NET 已经走在 Web 开发的最前沿。
当然，任何事情没有绝对的完美，在 .NET Framework 1.1( 也就是 .NET 的第二个版本 ) 之前，太多的 Postback 也是让开发人员抱怨之处，而且采用 WebForm 的开发方式让很多开发人员不是那么容易的处理客户端脚本，所有的事件实现都是依赖于 ViewState ，因此在低带宽下的网络应用，不断地提交也让有些用户感到“恼火”。
这个世界没有绝对的完美，但是会一点一点走向完美，也许 ASP.NET 2.0 就有太多东西值得期待。
ADO.NET
相信大家不会忘记 ADO （ ActiveX Data Object ） , 我想 Windows 上面数据库开发流行它功不可没，通过统一的接口来实现对于数据库的访问，从而屏蔽复杂的数据库访问协议。而到了 .NET 时代， ADO.NET 进一步将数据访问“进化”，不要以为 ADO.NET 只是 ADO 的一个升级，在 ADO 的技术上提供了一个托管类库，除了都是数据访问框架，其他没有太多本质的关联。
虽然 ADO.NET 带来的震撼远远不如其他技术，可依然有很多东西值得我们去欣喜，毕竟创新总是一件好事情，何况是这个最成功的软件公司带来的创新，那么我们就来看看到底带来了什么：
1．除了提供了传统 ADO 的 Connection,Command 以外，我们意外的没有看到 Recordset 这样的对象，而是提供了 DataReader 用来处理向前滚动的数据访问，最最重要的是加入了 DataSet 这样的概念，因为如此，我们能够实现很多数据库应用中需要的“ Disconnected Application ”，能够实现“ InProc-Database ”，而这一切，通过 DataSet 能