谈Microsoft .NET战略
类别: ASP.NET教程 
在蹉跎中一路前行
――谈Microsoft .NET战略
Eric Liu（刘如鸿） 2004年《程序员》杂志第六期
题记
四年的时间对于历史而言只是沧海一粟，而对于一个商业公司而言，却足以重生几回。从微软提出.NET战略到现在也接近四年了，而今的我们应该怎样去看待.NET四年走过的历程，怎样去评价.NET战略。
从职业角度来讲，过去的半年实在是疯狂，绝对的疯狂，至少我是这样。其中有很多原因，但最重要的一个原因实际上是我们公司正在经历的变迁。而今天所作的介绍从某种意义上可以说，许多人、尤其是我，度过了无数个不眠之夜、花费了无数心血来认真思考这场变革。但是从某种意义上讲，正是这一变革，促使比尔・盖茨在年初作出了重要决策。我们确实花费了全部时间来认真考虑新一代的互联网会是什么样，怎样把如此众多的部分，包括我们已经做过的一些开发，完美地结合起来，继续保持世界领先地位，成为100%的比尔・盖茨时代。
微软总裁兼首席执行官――史蒂夫・鲍尔默
.NET的激情起航
2000年6月22日，这是一个所有“微软人”都应该记住的日子，因为从这一天起，微软公司将下一场赌注，一场押上全部身家的世纪豪赌――这一天，比尔.盖茨向全球宣布其下一代软件和服务，即Microsoft .NET平台的构想和实施步骤。新一代的Microsoft .NET 家族产品和技术替代了此前“下一代Windows服务(NGWS)”的提法，它涵盖了帮助软件开发商构建下一代互联网服务和给予新一代智能互联网设备强大功能的软件。此外，微软还宣布了基于.NET 平台的新产品计划，其中包括新一代的微软Windows操作系统、Windows DNA服务器、微软Office、MSN互联网网络服务、Visual Studio开发系统。
这样的决定对于当时已经全球领先的微软而言，无疑是“押宝”，将未来十几年内的发展押给了他们构筑的.NET，当然也正是从那一刻开始，这家全球最大的软件公司也会不会遗力的去推进这个“伟大的梦想”。
那时的.NET
什么是.NET？.NET有什么？有人也认为是微软故意模糊概念，实际的.NET是Windows DNA(Distributed Network Architecture)和COM+的一个延续，在本质上没有改变。虽然这样的理解有时偏频，但是问题是明显的，我们不是那么容易的理解“什么是.NET”。
2000年微软的白皮书这样定义.NET：Microsoft® .NET 是Microsoft XML Web Services 平台。XML Web Services 允许应用程序通过 Internet 进行通讯和共享数据，而不管所采用的是哪种操作系统、设备或编程语言。Microsoft .NET 平台提供创建 XML Web services 并将这些服务集成在一起之所需。对个人用户的好处是无缝的、吸引人的体验。
我们可以清楚的看到微软对于.NET的理解是XML Web Services的平台，一切皆是服务，下一代的Internet应用将是依赖于Web Service来构建，Microsoft .NET 平台由以下技术构成：
l .NET用户体验
l .NET基础设施和工具
l .NET服务构造块
l .NET设备软件
用户永远是上帝，脱离用户讨论战略没有实际意义，为此除开倡导的平台核心技术以外，微软还承诺对于个人用户提供.NET用户体验，其中包括：
Windows .NET
MSN .NET
用户订购服务
Office .NET
bCentral for .NET
Visual Studio .NET
从这些文字我们可以看出，微软几乎可以将自己的全部产品加上“.NET”的字眼，但是那是不是因为着这就是“.NET”?
Everything is .NET
大概是为了强化.NET在人们心目中的印象，微软此时开展了一场dotnetialization（.NET化）运动，几乎所有传统的、创新的和虚构的产品都被打上“.NET”的标签。
为了扩展.NET战略的宣传，微软将其很多仍使用传统技术的产品都加上了“.NET”字眼。最典型的莫过于2000年底发布的.NET Enterprise Server系列。这套服务器软件虽然打上了.NET标签，但与.NET技术没有任何关系。
真正创新的思想是Web Service。微软当时极力推动Web Service从概念走入应用的最核心。
此外，微软还虚构了、或者至少是过早描绘了一些新的、以“.NET”命名的产品与服务。
一切都是.NET，微软这样做的结果就是将.NET这个品牌叫得路人皆知，而其实质概念则几乎没有人了解。除了提供一些开发工具的支持，其他方面的.NET推进有点做作的感觉，更加实际的来说.NET战略只是一个CLR的平台，其他方面的概念解释都让人牵强。
艰难晦涩的.NET改变终于带入微软走入了一个尴尬的境地，.NET Enterprise Server就如同水中望月，而Office XP的推出除了绚丽的图形表现界面以外，也没有太多东西让人发现和.NET有关，这是一段迷惘而痛苦的岁月。
迷惘
经过一年多的喧嚣，.NET已经渐渐热起来，越来越多的人开始使用.NET，至少开始关注这个平台，C#的正确发音已经尽人皆知。但是，看得出来，微软自己对于.NET的态度已经发生了微妙的变化。原来的计划太庞大，即使微软这样的巨人也无法掌控。前面的路应该怎么走？微软也产生了迷惘。
2001年5月31日Office XP正式发布，它显然不是“传说”中的Office.NET。微软强调这个XP版本加大的是“体验”（experience）及其网络的整合，而“用户体验”和与网络的融合都是“.NET战略”的一部分。但是，实质的改进有什么呢？除了返璞归真的平面图形菜单（戏剧性的是这样的界面成了日后众多软件界面模仿的对象），和内建支持了SOAP工具包及其联机搜索能力，我们发现和当初预想的Office.NET有天壤之别。
Office开发采取滚动方式进行，也就是在发布Office XP之前，下一版Office已经在开发中。据说部真的正在开发一个雄心勃勃的Office.NET。在这一激进的计划中，所有的访问都是通过Web Service来完成的，应用程序与网络的融合史无前例。不幸的是，这个产品最终流产，并且直接导致一个副总裁的辞职。究竟是技术上太不现实，还是微软意识到这个产品无法被用户接受？我们已经不得而知。
如果说Office曾经太激进，那么那些支持IT应用基础架构的应用服务器又是如何呢？在商业应用中的Commerce Server 2002，Biztalk Server 2002，Content Management Server 2002等等，虽然在一定程度加上了.NET Framework的支持，但是感觉有点是被微软强行联姻的“亲家”罢了，Visual Studio .NET对于其开发的支持依然是一种有心无力的感觉，并且这写服务器提供的并不是完整的托管类库，很大一部分功能仍然需要通过COM的方式来完成访问。.NET是一个庞大的战略，但是在短短的时间内希望完成到一个新的平台的迁移不是那么容易的事情，而此时.NET Enterprise Server系列的2002版本虽然在一个.NET的名头下依然是一个服务器群集，但是根本无法体现出.NET曾经的设想。
此时的VS.NET有点孤军奋战的感觉，毕竟和其他应用服务器的结合不是那么尽如人意，并且在Managed C++方面的表现也不足以作为系统级开发的利器，因此还是有些人在等待，而不会去考虑将已有的应用全部迁移到.NET平台上来。
所有这些情况，不仅体现了，同时也导致了微软的困惑。一个技术概念，如果不能与切实可用的产品结合起来，就会变成空中楼阁。
对于用户而言，最重要的是能够实际带来什么，而不是仅仅带来概念，经历了那段迷惘，微软对于.NET的理解终于“尘归尘，土归土”，穿过水花镜月，一路坚定的走来。
务实
? 2002年7月24日，比尔•盖茨在一个内部讲话中承认说，2000年9月推出的.NET企业服务器称作.NET“是有点草率”，也正是从这个时候开始微软真正开始反思.NET战略是否太过泛滥，是否超出了他们所能够控制的范围。
在反思中摒弃浮躁，在务实中前行，经过两年时间的喧嚣和反思，.NET正在一点一点地走进现实应用。
? 2003年4月25日，曾被命名为Windows .NET Server的Windows Server 2003正式发布。Windows Server 2003此前曾四易其名，它是第一个内置支持.NET Framework 1.1的Windows操作系统，因此有资格戴上.NET的标签，但最终确定的名称中并没有包括“.NET”字样，出乎很多人的预料。
同日，微软发布了基于.NET Framework开发工具的第二个版本，也就是Visual Studio.NET 2003，经历了一年的发展，2003版本终于被越来越多的开发人员所接受，除了修正了2002版本的一些细节性错误，在类库方面也更加强健和良好的兼容。
也也就是从此刻开始，VS.NET成为一个最强大的开发平台，多语言集成的开发环境，开发人员不仅可以开发传统的Windows应用，能够开发Web应用程序，同时在移动开发，企业级组件方面都提供了良好的支持。
Office.NET已经渐渐淡去，此刻的微软也明白一相情愿设计一个完全以Web Service为中心的Office版本至少在今天是不可行的。2003年10月27号的时候发布最新版本的Office 2003中，启用了一个比较保守的命名――Office System 2003。从此Office不再是一个纯粹的客户端软件，而是一个完整的企业信息应用平台，不过相对于神话般的Office.NET，还有很长的路需要走，不过我们可以肯定，神话仅仅是神话，这个时候的微软已经知道.NET对于用户意味着什么。
在服务器系统方面，.NET Enterprise Server有点盛名难负，更加直接的来说是一个虚构的名字。为了更加贴近实际情况，微软将新版服务器系统命名为Windows Server System，旨在建立一个深度集成的服务器基础结构，而从使IT专业人员能够将精力集中到满足业务需求方面。
这一切表明，微软在.NET的推广策略上已经趋于务实。事实上，一项新技术，必须有现实的产品支撑。微软一向的做法，是将新技术与自己的强势产品结合，从而让最终用户的需求推动开发者转向微软技术。然而，在.NET推广之初，这一策略并没有很好的贯彻。只是经过了这个务实阶段之后，微软才重新回到了自己的正确路线上。将.NET技术与Windows和Office两大拳头产品结合，这表明.NET已经迈上稳健发展之路。
未来展望
Longhorn需要到2006年才能够发布，我们完全可以认为，这个就是四年以前微软提出的.NET战略时希望达成的梦想之一，集成互联，同时拥有一个非常出色的用户体验。微软当初承诺在三年内实现这些基础架构的建设，现在看来这个时间恰好需要多一倍，也就是整整六年的时间。这个号称完全重新构建的操作系统才能够称得上.NET操作系统，关于其中的Avalon(图形渲染技术)、Indigo（通信子系统）、WinFS（文件存储系统）还有纯粹的.NET编程接口WinFX。
相信2006年的Longhorn发布的时候，.NET应该已经得到业界的认同，并且已经出现了相当部分基于.NET的成功案例，对于.NET的FUD(Fear/Uncertainty/Doubt，恐惧/不确定性/疑虑)也已经烟消云散，.NET和J2EE真正意义的站在同一个水平线上去对话。
而在Longhorn中的Indigo子系统，则以一种更加透明的方式来实现系统的部署，于是“一次编写，多次部署”也成为可能。随着.NET提出微软一直倡导的Smart Client技术也得到完美的体现，这个时候已经可以不去考虑桌面和浏览器的区别，如果说有，那么只是一种部署方式的差异，而解决这个问题的核心在于XAML及其和Win32 API等同的WinFX技术。
“一切皆是Web Service”，那个时候的确可以做到当初.NET战略希望的所有子系统都通过Web Service通信（当然了，那个时候的Web Service不再是今天的效率）。期待总是期待，毕竟还有两年的时间去观望，也许到了日后一切全部变了样。
但是我们相信，未来的.NET会成功，就如同微软一贯以来的成功，于是今天我们不是考虑是否使用.NET而是考虑何时选择.NET，当然，每一次的选择和放弃都是一种痛苦。
不知道是刻意或是纯粹出于偶然，营销名词和技术名称以及通用词汇竟然都在同一个时间点代表了同样的意义：过去与现在，传统与流行。
.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年。
“我们离破产只有18个月”，这是全球最成功的软件公司对于自己的告诫，于是他始终走在最前端，通过概念――务实――再概念的循环一次又一次的改变自己，同时改变了整个世界。
.NET改变了什么？
Microsoft，是否依旧“Micro”？
原先的Microsoft已经不再“Micro”，20多年的高速成长，这家从PC起家的软件公司已经早早称霸全球，除了在PC机方面保持绝对的垄断优势以外，在服务器市场，也已经发起对于高端应用的冲击，Windows 2000就是这个战役的经典之作，按照一贯的策略，微软依赖其价格优势和最简单的操作界面一点一点地换取中小企业的“芳心”，而对于大企业应用，虽然还无法改变其“小丑”形象，但是显而易见，那样的关系越来越“暧昧”。
评论界很多人都认为微软是一个以销售起家的公司，毕竟微软的技术从来不是最好，却能够笑到最后，我们无法否认过去很长一段时间微软是依靠Windows和Office的销售来支撑整个公司的高速运转，但.NET战略的推出则展现出微软从销售型转向服务型企业。毕竟随着技术的发展，在操作系统和办公软件上面的利润已经越来越透明，加上Linux的冲击和微软自身旧产品如Windows 98，Office 97等等已经足够“好用”，这样带来的结果必然是企业IT采购成本的大幅度缩减，微软自身也必须找寻更好的商业模式来获取稳定的收入。
将“Windows时代”带入“.NET时代”，对于微软公司而言，需要做的有很多很多，包括自身定位，包括如何打破用户的顾虑和恐惧，当然还有一直以来不是很友好的公关形象。于是.NET战略成了微软一个新的战场。
改变了开发人员
很多人在会抱怨新的技术更新太快了，如果跟着微软走总是需要不断地学习新技术，而相对来说其他的技术更新就没有如此之外，至少能够保持一段时期的稳定，这点就从C++那么多年以来的发展还有Java就可以看得出来。
不过，世界总是在变化，有很多东西总是在不断改变，与其拒绝变化然后徘徊不前，不如去拥抱变化，当然这里提到的并不是盲动的跟随改变，然后成为“语言学习机器”。4年的发展，.NET已经渐渐的成长为可以和J2EE对抗的应用平台，并且在中低端的应用开发中，能够显著的提高生产力，这是何乐而不为。
不过微软在.NET的营销并不是非常成功而干脆，至少在Web Service方面对于广大的开发人员是一种误导，这个世界没有绝对的“银弹”，Java不是，.NET也不会是，而XML Web Service在微软自身的定位的反复不定也让人有点疲惫。
带来一个新的选择，带来更高的生产力，带来一种新的理念， 作为一线的开发人员，我们曾经为选择一个工具或者平台困惑、迷惘、狂热、追逐，最后坚定或者放弃。
这个世界本来就是一个需要不断探索的世界，.NET同样如此。从总体上来说.NET，经历从狂热到迷惘，在到务实，从而逐步走向成熟的过程。
――谈Microsoft .NET战略
Eric Liu（刘如鸿） 2004年《程序员》杂志第六期
题记
四年的时间对于历史而言只是沧海一粟，而对于一个商业公司而言，却足以重生几回。从微软提出.NET战略到现在也接近四年了，而今的我们应该怎样去看待.NET四年走过的历程，怎样去评价.NET战略。
从职业角度来讲，过去的半年实在是疯狂，绝对的疯狂，至少我是这样。其中有很多原因，但最重要的一个原因实际上是我们公司正在经历的变迁。而今天所作的介绍从某种意义上可以说，许多人、尤其是我，度过了无数个不眠之夜、花费了无数心血来认真思考这场变革。但是从某种意义上讲，正是这一变革，促使比尔・盖茨在年初作出了重要决策。我们确实花费了全部时间来认真考虑新一代的互联网会是什么样，怎样把如此众多的部分，包括我们已经做过的一些开发，完美地结合起来，继续保持世界领先地位，成为100%的比尔・盖茨时代。
微软总裁兼首席执行官――史蒂夫・鲍尔默
.NET的激情起航
2000年6月22日，这是一个所有“微软人”都应该记住的日子，因为从这一天起，微软公司将下一场赌注，一场押上全部身家的世纪豪赌――这一天，比尔.盖茨向全球宣布其下一代软件和服务，即Microsoft .NET平台的构想和实施步骤。新一代的Microsoft .NET 家族产品和技术替代了此前“下一代Windows服务(NGWS)”的提法，它涵盖了帮助软件开发商构建下一代互联网服务和给予新一代智能互联网设备强大功能的软件。此外，微软还宣布了基于.NET 平台的新产品计划，其中包括新一代的微软Windows操作系统、Windows DNA服务器、微软Office、MSN互联网网络服务、Visual Studio开发系统。
这样的决定对于当时已经全球领先的微软而言，无疑是“押宝”，将未来十几年内的发展押给了他们构筑的.NET，当然也正是从那一刻开始，这家全球最大的软件公司也会不会遗力的去推进这个“伟大的梦想”。
那时的.NET
什么是.NET？.NET有什么？有人也认为是微软故意模糊概念，实际的.NET是Windows DNA(Distributed Network Architecture)和COM+的一个延续，在本质上没有改变。虽然这样的理解有时偏频，但是问题是明显的，我们不是那么容易的理解“什么是.NET”。
2000年微软的白皮书这样定义.NET：Microsoft® .NET 是Microsoft XML Web Services 平台。XML Web Services 允许应用程序通过 Internet 进行通讯和共享数据，而不管所采用的是哪种操作系统、设备或编程语言。Microsoft .NET 平台提供创建 XML Web services 并将这些服务集成在一起之所需。对个人用户的好处是无缝的、吸引人的体验。
我们可以清楚的看到微软对于.NET的理解是XML Web Services的平台，一切皆是服务，下一代的Internet应用将是依赖于Web Service来构建，Microsoft .NET 平台由以下技术构成：
l .NET用户体验
l .NET基础设施和工具
l .NET服务构造块
l .NET设备软件
用户永远是上帝，脱离用户讨论战略没有实际意义，为此除开倡导的平台核心技术以外，微软还承诺对于个人用户提供.NET用户体验，其中包括：
Windows .NET
MSN .NET
用户订购服务
Office .NET
bCentral for .NET
Visual Studio .NET
从这些文字我们可以看出，微软几乎可以将自己的全部产品加上“.NET”的字眼，但是那是不是因为着这就是“.NET”?
Everything is .NET
大概是为了强化.NET在人们心目中的印象，微软此时开展了一场dotnetialization（.NET化）运动，几乎所有传统的、创新的和虚构的产品都被打上“.NET”的标签。
为了扩展.NET战略的宣传，微软将其很多仍使用传统技术的产品都加上了“.NET”字眼。最典型的莫过于2000年底发布的.NET Enterprise Server系列。这套服务器软件虽然打上了.NET标签，但与.NET技术没有任何关系。
真正创新的思想是Web Service。微软当时极力推动Web Service从概念走入应用的最核心。
此外，微软还虚构了、或者至少是过早描绘了一些新的、以“.NET”命名的产品与服务。
一切都是.NET，微软这样做的结果就是将.NET这个品牌叫得路人皆知，而其实质概念则几乎没有人了解。除了提供一些开发工具的支持，其他方面的.NET推进有点做作的感觉，更加实际的来说.NET战略只是一个CLR的平台，其他方面的概念解释都让人牵强。
艰难晦涩的.NET改变终于带入微软走入了一个尴尬的境地，.NET Enterprise Server就如同水中望月，而Office XP的推出除了绚丽的图形表现界面以外，也没有太多东西让人发现和.NET有关，这是一段迷惘而痛苦的岁月。
迷惘
经过一年多的喧嚣，.NET已经渐渐热起来，越来越多的人开始使用.NET，至少开始关注这个平台，C#的正确发音已经尽人皆知。但是，看得出来，微软自己对于.NET的态度已经发生了微妙的变化。原来的计划太庞大，即使微软这样的巨人也无法掌控。前面的路应该怎么走？微软也产生了迷惘。
2001年5月31日Office XP正式发布，它显然不是“传说”中的Office.NET。微软强调这个XP版本加大的是“体验”（experience）及其网络的整合，而“用户体验”和与网络的融合都是“.NET战略”的一部分。但是，实质的改进有什么呢？除了返璞归真的平面图形菜单（戏剧性的是这样的界面成了日后众多软件界面模仿的对象），和内建支持了SOAP工具包及其联机搜索能力，我们发现和当初预想的Office.NET有天壤之别。
Office开发采取滚动方式进行，也就是在发布Office XP之前，下一版Office已经在开发中。据说部真的正在开发一个雄心勃勃的Office.NET。在这一激进的计划中，所有的访问都是通过Web Service来完成的，应用程序与网络的融合史无前例。不幸的是，这个产品最终流产，并且直接导致一个副总裁的辞职。究竟是技术上太不现实，还是微软意识到这个产品无法被用户接受？我们已经不得而知。
如果说Office曾经太激进，那么那些支持IT应用基础架构的应用服务器又是如何呢？在商业应用中的Commerce Server 2002，Biztalk Server 2002，Content Management Server 2002等等，虽然在一定程度加上了.NET Framework的支持，但是感觉有点是被微软强行联姻的“亲家”罢了，Visual Studio .NET对于其开发的支持依然是一种有心无力的感觉，并且这写服务器提供的并不是完整的托管类库，很大一部分功能仍然需要通过COM的方式来完成访问。.NET是一个庞大的战略，但是在短短的时间内希望完成到一个新的平台的迁移不是那么容易的事情，而此时.NET Enterprise Server系列的2002版本虽然在一个.NET的名头下依然是一个服务器群集，但是根本无法体现出.NET曾经的设想。
此时的VS.NET有点孤军奋战的感觉，毕竟和其他应用服务器的结合不是那么尽如人意，并且在Managed C++方面的表现也不足以作为系统级开发的利器，因此还是有些人在等待，而不会去考虑将已有的应用全部迁移到.NET平台上来。
所有这些情况，不仅体现了，同时也导致了微软的困惑。一个技术概念，如果不能与切实可用的产品结合起来，就会变成空中楼阁。
对于用户而言，最重要的是能够实际带来什么，而不是仅仅带来概念，经历了那段迷惘，微软对于.NET的理解终于“尘归尘，土归土”，穿过水花镜月，一路坚定的走来。
务实
? 2002年7月24日，比尔•盖茨在一个内部讲话中承认说，2000年9月推出的.NET企业服务器称作.NET“是有点草率”，也正是从这个时候开始微软真正开始反思.NET战略是否太过泛滥，是否超出了他们所能够控制的范围。
在反思中摒弃浮躁，在务实中前行，经过两年时间的喧嚣和反思，.NET正在一点一点地走进现实应用。
? 2003年4月25日，曾被命名为Windows .NET Server的Windows Server 2003正式发布。Windows Server 2003此前曾四易其名，它是第一个内置支持.NET Framework 1.1的Windows操作系统，因此有资格戴上.NET的标签，但最终确定的名称中并没有包括“.NET”字样，出乎很多人的预料。
同日，微软发布了基于.NET Framework开发工具的第二个版本，也就是Visual Studio.NET 2003，经历了一年的发展，2003版本终于被越来越多的开发人员所接受，除了修正了2002版本的一些细节性错误，在类库方面也更加强健和良好的兼容。
也也就是从此刻开始，VS.NET成为一个最强大的开发平台，多语言集成的开发环境，开发人员不仅可以开发传统的Windows应用，能够开发Web应用程序，同时在移动开发，企业级组件方面都提供了良好的支持。
Office.NET已经渐渐淡去，此刻的微软也明白一相情愿设计一个完全以Web Service为中心的Office版本至少在今天是不可行的。2003年10月27号的时候发布最新版本的Office 2003中，启用了一个比较保守的命名――Office System 2003。从此Office不再是一个纯粹的客户端软件，而是一个完整的企业信息应用平台，不过相对于神话般的Office.NET，还有很长的路需要走，不过我们可以肯定，神话仅仅是神话，这个时候的微软已经知道.NET对于用户意味着什么。
在服务器系统方面，.NET Enterprise Server有点盛名难负，更加直接的来说是一个虚构的名字。为了更加贴近实际情况，微软将新版服务器系统命名为Windows Server System，旨在建立一个深度集成的服务器基础结构，而从使IT专业人员能够将精力集中到满足业务需求方面。
这一切表明，微软在.NET的推广策略上已经趋于务实。事实上，一项新技术，必须有现实的产品支撑。微软一向的做法，是将新技术与自己的强势产品结合，从而让最终用户的需求推动开发者转向微软技术。然而，在.NET推广之初，这一策略并没有很好的贯彻。只是经过了这个务实阶段之后，微软才重新回到了自己的正确路线上。将.NET技术与Windows和Office两大拳头产品结合，这表明.NET已经迈上稳健发展之路。
未来展望
Longhorn需要到2006年才能够发布，我们完全可以认为，这个就是四年以前微软提出的.NET战略时希望达成的梦想之一，集成互联，同时拥有一个非常出色的用户体验。微软当初承诺在三年内实现这些基础架构的建设，现在看来这个时间恰好需要多一倍，也就是整整六年的时间。这个号称完全重新构建的操作系统才能够称得上.NET操作系统，关于其中的Avalon(图形渲染技术)、Indigo（通信子系统）、WinFS（文件存储系统）还有纯粹的.NET编程接口WinFX。
相信2006年的Longhorn发布的时候，.NET应该已经得到业界的认同，并且已经出现了相当部分基于.NET的成功案例，对于.NET的FUD(Fear/Uncertainty/Doubt，恐惧/不确定性/疑虑)也已经烟消云散，.NET和J2EE真正意义的站在同一个水平线上去对话。
而在Longhorn中的Indigo子系统，则以一种更加透明的方式来实现系统的部署，于是“一次编写，多次部署”也成为可能。随着.NET提出微软一直倡导的Smart Client技术也得到完美的体现，这个时候已经可以不去考虑桌面和浏览器的区别，如果说有，那么只是一种部署方式的差异，而解决这个问题的核心在于XAML及其和Win32 API等同的WinFX技术。
“一切皆是Web Service”，那个时候的确可以做到当初.NET战略希望的所有子系统都通过Web Service通信（当然了，那个时候的Web Service不再是今天的效率）。期待总是期待，毕竟还有两年的时间去观望，也许到了日后一切全部变了样。
但是我们相信，未来的.NET会成功，就如同微软一贯以来的成功，于是今天我们不是考虑是否使用.NET而是考虑何时选择.NET，当然，每一次的选择和放弃都是一种痛苦。
不知道是刻意或是纯粹出于偶然，营销名词和技术名称以及通用词汇竟然都在同一个时间点代表了同样的意义：过去与现在，传统与流行。
.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年。
“我们离破产只有18个月”，这是全球最成功的软件公司对于自己的告诫，于是他始终走在最前端，通过概念――务实――再概念的循环一次又一次的改变自己，同时改变了整个世界。
.NET改变了什么？
Microsoft，是否依旧“Micro”？
原先的Microsoft已经不再“Micro”，20多年的高速成长，这家从PC起家的软件公司已经早早称霸全球，除了在PC机方面保持绝对的垄断优势以外，在服务器市场，也已经发起对于高端应用的冲击，Windows 2000就是这个战役的经典之作，按照一贯的策略，微软依赖其价格优势和最简单的操作界面一点一点地换取中小企业的“芳心”，而对于大企业应用，虽然还无法改变其“小丑”形象，但是显而易见，那样的关系越来越“暧昧”。
评论界很多人都认为微软是一个以销售起家的公司，毕竟微软的技术从来不是最好，却能够笑到最后，我们无法否认过去很长一段时间微软是依靠Windows和Office的销售来支撑整个公司的高速运转，但.NET战略的推出则展现出微软从销售型转向服务型企业。毕竟随着技术的发展，在操作系统和办公软件上面的利润已经越来越透明，加上Linux的冲击和微软自身旧产品如Windows 98，Office 97等等已经足够“好用”，这样带来的结果必然是企业IT采购成本的大幅度缩减，微软自身也必须找寻更好的商业模式来获取稳定的收入。
将“Windows时代”带入“.NET时代”，对于微软公司而言，需要做的有很多很多，包括自身定位，包括如何打破用户的顾虑和恐惧，当然还有一直以来不是很友好的公关形象。于是.NET战略成了微软一个新的战场。
改变了开发人员
很多人在会抱怨新的技术更新太快了，如果跟着微软走总是需要不断地学习新技术，而相对来说其他的技术更新就没有如此之外，至少能够保持一段时期的稳定，这点就从C++那么多年以来的发展还有Java就可以看得出来。
不过，世界总是在变化，有很多东西总是在不断改变，与其拒绝变化然后徘徊不前，不如去拥抱变化，当然这里提到的并不是盲动的跟随改变，然后成为“语言学习机器”。4年的发展，.NET已经渐渐的成长为可以和J2EE对抗的应用平台，并且在中低端的应用开发中，能够显著的提高生产力，这是何乐而不为。
不过微软在.NET的营销并不是非常成功而干脆，至少在Web Service方面对于广大的开发人员是一种误导，这个世界没有绝对的“银弹”，Java不是，.NET也不会是，而XML Web Service在微软自身的定位的反复不定也让人有点疲惫。
带来一个新的选择，带来更高的生产力，带来一种新的理念， 作为一线的开发人员，我们曾经为选择一个工具或者平台困惑、迷惘、狂热、追逐，最后坚定或者放弃。
这个世界本来就是一个需要不断探索的世界，.NET同样如此。从总体上来说.NET，经历从狂热到迷惘，在到务实，从而逐步走向成熟的过程。
