现在也许你会因为没有听说过微软的新.NET战略而感到很没有面子。根据你从与别人聊天中或者在你的阅读中得来的信息，你心目中的.NET或许是一个针对整个基于分布式结构的Internet的宏伟的建筑，或者仅仅是web应用程序的别名而已。但是有一件事倒是越发清楚了，那就是大家对什么是.NET，还有.Net对Web和应用程序开发这意味着什么是越发困惑了。

我不敢自称为.NET的专家，但我想我已经足够多的介入到了它的设计、开发过程之中，所以我能够提供一些有用的信息以帮助大家明白.NET的定位、目的和目标。所以虽然接下来的内容并不提供开发级的信息，不能告诉你怎样使用.NET开发程序，但确实能够给你一些指引，使你至少能够为你的同事或家人讲述.Net。

回忆过去
首先，我们要回去看看新的编程模式是怎样进化成为操作系统的一部分的。现在设想一下我们回到了80年代初。那时，在考虑购买一台计算机的时候，IBM个人电脑已经开始成为众多的选择对象之一了。它的操作系统是MS-DOS，和那时几乎所有的操作系统一样，这是个严格的命令行的，基于文本的操作系统。

虽然当时绝大多数的应用程序在这些早期的计算机的基于文本的环境中运行良好，但有些程序员开始接受挑战去创造属于他们自己的，图形化的环境。用户首先用基于文本的的操作系统启动，然后运行程序切换到图形模式。这类的程序有的比较简单，只提供很少的功能，而有的则相对强大，功能多样。
要为这些程序设计和实现一套图形用户接口（GUI）库需要做相当多的工作。特别痛苦的是在这些不同的实现中几乎没有任何共同点。要完全实现一个真正强大的GUI，需要从操作系统级做起。所以到后来，apple，microsoft和其他公司开发出了图形界面的操作系统，这些系统不仅支持开发GUI的应用程序，还极大地扩展了这些程序的能力，其提供的库不单单是支持窗口和菜单的绘制，还提供了丰富的的系统服务，以使开发者工作更加流畅。这些服务包括与设备无关的打印模式，甚至是系统剪贴板等等，这些都是对开发者非常有用的资源。

我希望我对这段历史得还算清楚，我们将从这里开始。

回到现在
现在我们跳回到现在。想象一下Internet正扮演着80年代初个人电脑的角色，Web站点就是当初的程序。如果这个Web站点只是包括一些超链或者是一些文本文档，那它就像是过去的一个文本模式的程序，如果这个站点提供交互式的服务的话，那它就可以被比作是当时的GUI的程序了。在交互式的服务下，用户提供信息给Web站点，这些信息在Web站点中被交给应用程序逻辑来处理然后产生一个结果。这样的例子有购物车、AltaVista提供的翻译服务和UPS提供的包裹跟踪服务等等。

首先来看看购物车这个例子。几乎所有的购物车都将支持输入信用卡信息。很多时候这些信息只是作为交易信息的一部分而被记录下来，一个好的购物车将应该能够快速而且精确的向信用卡的发卡公司校验信用卡信息，如果用户输入了错误的信息，就应当给用户一个提醒。但当这个Web站点想支持一种新的信用卡类型时它该怎么办呢？这个站点的开发者必须联系那个信用卡公司，找出他们支持的(如果有的话)电子校验服务，然后根据那个公司的电子校验的实现写自己的代码与其配合。

翻译服务又会怎么样呢？如果我们正在写一个e-mail 的程序，难道你不觉得在你的程序中加入即时翻译功能会非常有用吗？Altavista就有提供了这种服务的站点，你可以悄悄的启动一个隐藏的浏览器控件，给它一些必要的信息，然后查看它返回的信息，在返回的页面上定位翻译好了的信息的位置，最后把它提取出来提供给用户。这和有些图形界面的应用程序从文本模式的程序或者是大型计算机终端中获取信息的方式有些类似。这就是广为所知的屏幕截取，这种方式比较复杂而且相当脆弱，因为目标屏幕的布局发生变化，即使是很细微的变化将会带来很严重的问题，而且在有些情况下这种实现显得并不道德。

现在我们来讨论讨论包裹跟踪服务，想象一下如果你的站点允许你的用户查询他们所定购的货物的当前状态会是会多么棒呀。通过UPS的追踪编号来提供这些信息将会是非常有效的，或者是把这些信息做成到UPS站点的链接，然后你的用户就会得到关于他们包裹目前状态的详细报告了，也许这个时候这些包裹还正在漂洋过海呢。但你觉不觉得这样会更方便，那就是你的站点和UPS的站点交互工作，然后在你自己的网站上提供这些信息？这样的话，这些信息就会和你的站点的其它部分一样共享相同的用户界面，而且不用担心用户不小心迷失在UPS站点后不知道怎样回到你的站点了。

为了给用户提供集成服务的体验，上面的例子或者需要你从其他公司找到以编程方式得到他们的服务的方法，然后为这些服务开发自己的用户界面；或者是写一个屏幕截取程序来截取相应的信息，如果已有公司通过Web 提供了的相同服务的话。
非常明显，无论是那种实现方式，代码量和耦合度都太大，而且还存在很多潜在的问题和失灵的可能。这些途径在本质上很象80年代时强迫文本模式的程序与操作系统还不能直接支持的设备进行交互一样。

标准协议
一种比较好的解决方案应该是一套通用的、能够和远程服务交互的途径，这种途径不仅仅连接能够某个公司的服务，而且能够发现这个公司提供什么样的服务，就象XML、SOAP和UDDI的目标那样。XML(扩展的标记语言)将信息表示成一种易于按你的需要进行编程获取或处理的格式，SOAP(Simple Object Access Protocol)基于XML，特别的被设计来提供远程服务的接口信息。而UDDI(Universal Description, Discovery, and Intergration)是业界倡导的，具有对Internet服务和资源的探测能力的一套标准。
在方便的连接和利用另一个站点所愿意提供的服务这条漫漫长路上，这些标准接口正在努力前行。但是由于当前的操作系统还不能够直接支持XML/SOAP，你必须在跳过一些障碍后才能使用这些接口。你可以写你自己的基于XML的编译引擎，或者使用别人的，然后与XML文档对象模型进行交互，创建出和检验被来回传递的数据。这很有意义，而且绝对比求助于屏幕截取容易多了。
进入.NET
更好的解决方案是所有的XML/SOAP/UDDI都能够被操作系统直接支持，然后由操作系统把它们作为相当普通的函数调用或者是对象的交互来向你提供。例如，下面的这些东西提供了一种绝妙的方法来供应用程序调用AltaVista的翻译服务。
   avTrans = new AVTranslation (“Here is a sample line of text”, “English”);
   strResult = avTrans.translateTo (“French”);
这就是.NET的给我们带来的好处之一。它不仅允许应用程序直接访问和利用远程的基于Web的服务，而且使得Web服务器很容易地向外部的程序提供这种服务。这并不意味着提供web服务器要提供服务，客户端要利用Web服务都非得要用.Net不可，只不过是指利用.NET平台来进行这些开发更加便利而已。
属性、方法和事件。哦，我的天！
.NET的设计，当然不是只停止在Internet接口这个层面上。访问远程服务的这种编程模型同样也被应用在本地服务的利用与内部事务逻辑上。换句话说，这个编程模式将遍布在普遍的程序的设计中。
其目的在于提供一种统一的、面向组件的编程模型。无论你想显示一个远程的翻译服务还是本机的文件系统或者是一个对话框，所有的支持都将是一个一般化的基于组件的接口：属性、方法和事件。支持的.NET的编程语言可以容易而且融洽地使用这些组件，而不管这些组件使用什么样的语言开发的，所有的这些语言都是平等的公民，一个VB应用程序就能调用用C++编写的组件的方法，同时捕获Cobol开发的应用程序触发的事件。而且协作者们再也不会意识到自己的伙伴在用另外的一种编程语言。
肯定的，应用程序在利用这些服务以及架构的优势上也是会分成很多层次的。你可你想象一下你曾经在使用一台连在一台大型机的电传打字机终端，有人向你解释图形界面的应用程序是什么样的，用多快的时间你就会掌握滚动条，组合框，菜单条以其调色板管理的精髓呢？.NET就像在引出一种全新的开发应用程序的思考方法。如果你仅看到了它的一部分，也许你不能发现它到底新在何处，而当你当你取得这个不可分割的整体的各方面的知识而且发现了其各部分如何协同工作后，你就会发现其中埋藏的巨大的兴奋，至少对我是这样。

我从来没有任何打算让这个对.NET的粗略的讨论深入到任何细节。我将在以后的文章中深入窥视.NET的特色和能力。