.NET重要技术思考
.NET Remoting
从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能够得到很好的解决。
2． 以更加透明的方式提供了数据库连接池，同时开发人员能够通过变成的方式控制具体的运行方式。
3． 提出DataAdapter，让开发人员能够以一种统一的方式去访问异种数据库，唯一的区别在于具体适配器的实现不同罢了。
4． “Typed Dataset”让开发人员能够非常方便的将DataSet 中的Table、Field映射到自定义类。
5． 对于XML提供了良好的支持，所有的DataSet都能够非常容易的系列化或者反系列化成XML文档。
当然ADO.NET不是万能的，在数据持久层（Data Presistent Layer）方面的支持显然不如Java，到现在为止都没有一个很好的O/R Mapping工具，而Java方面的Hibernate已经非常成熟，ADO.NET 2.0中的ObjectSapce也许能够改变目前的现状，就让我们耐心去等待，虽然需要到2005年。
从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能够得到很好的解决。
2． 以更加透明的方式提供了数据库连接池，同时开发人员能够通过变成的方式控制具体的运行方式。
3． 提出DataAdapter，让开发人员能够以一种统一的方式去访问异种数据库，唯一的区别在于具体适配器的实现不同罢了。
4． “Typed Dataset”让开发人员能够非常方便的将DataSet 中的Table、Field映射到自定义类。
5． 对于XML提供了良好的支持，所有的DataSet都能够非常容易的系列化或者反系列化成XML文档。
当然ADO.NET不是万能的，在数据持久层（Data Presistent Layer）方面的支持显然不如Java，到现在为止都没有一个很好的O/R Mapping工具，而Java方面的Hibernate已经非常成熟，ADO.NET 2.0中的ObjectSapce也许能够改变目前的现状，就让我们耐心去等待，虽然需要到2005年。