在前一篇文章中已经讨论过Microsoft 在设计和开发ASP＋时的主要动机。ASP非常成功，为什么
还要一个新版本？有4个问题需要考虑：

● 目前，ASP脚本主要是用基本的non-typed 语言，例如VBScript 和JScript来写的（除非你安装了一
个独立的语言解释程序）。尽管ASP第一次执行页面代码时确实进行分解和缓存，这一局限导致即使
在有优势的时候，也不能使用那些strongly-typed 的语言，例如Visual Basic 和C＋＋。而ASP＋为
Web 应用程序提供了真正中立于语言的执行框架。

● 创建包含着一长串各种代码、HTML、文本、对象声明混合在一起的大型ASP页也是非常容易的。
要再利用这些代码是很困难的，除非你将其放在独立的＇include＇ 文件中，这也不是个很好的办法。
在许多环境下，开发一个web 应用程序需要各方面的专业人员，例如，需要程序员来写代码，需要
设计师来使HTML看起来漂亮。让代码和内容混杂在一个双方都需要在其上进行操作的文件中使它们
很难在一起工作。而ASP＋ 提供代码和内容的真正分离。

● 在以前版本的ASP中，大多数事情都要靠写代码来完成。想维护表单域的状态吗？写代码。想
确认客户输入的数据吗？写代码。想发出一些简单的数据值吗？写代码。想缓存页面区优化性能吗？
写代码。而ASP＋ 用基于服务器的控制和从概念上来说同Visual Basic 表单工作的方式相同的事件
驱动运行范例介绍了一种真正的组件模型。新的ASP＋ 服务器控制是声明式的（需要它们做一些事情
时才需要声明它们），所以你就可以少写一些代码，实际上，大多数情况下根本就不用写任何代码。

● 世界是变化的。通过＇Internet device＇ ，例如移动电话、PDA、电视机顶盒、游戏控制台或
其他东西访问你的网站的用户比例很快就会超过使用PC和传统浏览器的用户。这就意味着我们不得
不在服务器上做更多的工作，来使我们的网页与这些不同的设备相兼容。我们不得不以全新的格式
创建输出，例如Wireless Markup Language (WML)。另外，除了要为运行创建WML，新的Internet
设备和商业应用程序还要求能够从Web应用程序发送和接收XML数据。现在用ASP做这些需要你手工
使用XML 分解，从XML 计划转换数据，或将数据转换成XML 。ASP＋ Web 服务使将页面剪裁得适应
特定设备变得很简单。

除此之外，分布式应用程序迅速变化的特性要求更快地开发、更加组件化、可再利用、更易于
展开和更广泛的平台支持。新的标准例如简单对象访问协议Simple Object Access Protocol
(SOAP), 新的商业需求例如business-to-business (B2B) 数据交换，要求用新技术产生输出和与
其它系统通讯。Web 应用程序和Web 站点也需要更加灵活和可升级的服务，这些ASP＋ 通过倾向于
积极的监控和应用程序失败时的自动重新启动，内存释放等等都提供了。

所以，要想满足这些要求，ASP必须要进行全面的修改来变成一个全新的编程环境。尽管目前
很少有可用于此的工具，Visual Studio 7.0 可以提供全面支持使创建ASP＋ 应用程序简单（包括
ASP＋ 页面和ASP＋ 服务）。丰富的、基于组件的、事件驱动的编程模型特意设计成“工具友好”，
而这种支持对于所有的Visual Studio 语言，包括VB, C＋＋和C#. 都可用。而你也可以确信第三方
的工具制造商也不会落后太多。
目前Web 开发人员面临的最大挑战是浏览器的兼容性问题和他们所要创建的网页的复杂程度
不断增加。要创建更加交互式的页面，又要利用各种浏览器的最新特色的，同时还要确定页面
在所有可能的浏览器上都能工作，简直是挥之不去的噩梦。

当然，使用这些正在兴起或已经在使用的新Internet 设备会使情况更糟糕。特别是，要创建
的网页对移动电话和传统浏览器客户提供相同用户级别的兼容性也成为可能。只能显示3行字符文
本的移动电话当然要限制创造性和用户交互性。

一个显然的解决办法是创建动态定位每个特定客户的输出？还是创建同一站点的多种版本，每
个客户一种版本。第二种方法可不诱人，许多人更倾向于第一种。但是这就意味着来自于每个用户
的每一次敲击都需要一些服务器侧的处理来指明创建哪种输出。

如果是这样，为什么不让这一过程自动化？到这，ASP＋ 介绍了服务器控制的概念，其中包含
普通任务和提供一个清楚的编程模型。它们还帮助处理对各种不同类型客户的定位。
ASP已经提供了在服务器上运行组件的机会，这些组件产生返回给用户的页面部分。ASP＋ 通过
服务器控制扩展了这一概念。将任何HTML元素转换成服务器控制所需要做的只是增加一个额外的
属性: runat="server"。

一页中的任何HTML元素都可以用这种方法做标记，然后ASP＋ 就在服务器上处理这些元素，然后
产生适合这一特定服务器的输出。另外作为副产品，我们还可以特别创造一个额外的小窍门，用
HTML 〈 FORM 〉 和控制元素相关联的表单创建代码，在到服务器的往返旅行中维护状态。这就使编程
的过程不那么单调，更具有创造性。

让HTML元素在服务器上执行的概念开始看来有点奇怪，你会发现它为页面的功能增加了一个全
新的层面，同时又更加容易编写。一个程序员还会再要求什么呢？
创建Web 站点和交互式应用程序时最讨厌的任务就是管理从HTML表单控制传递给服务器的值，
在页请求之间维护这些控制的值。所以ASP＋ 的核心目的之一就是简化这种编程任务。这对于程序员
来说不设计额外的工作，支持基本HTML的所有浏览器都能很好地完成。

看看代码的下一部分。用HTML控制创建一个简单表单，用户可以输入计算机名并选择操作系统。
这个例子本身没有什么了不起，但是它代表了一个相当普遍的情况，几乎现在每一个web 应用程序
都会用到。当表单被提交给服务器时，用户所选择的值就会从Request.Form 集合中提取出来，并
用Response.Write 方法显示：

〈 HTML 〉
〈 BODY 〉
〈 ％
If Len(Request.Form("selOpSys")) 〉 0 Then
strOpSys = Request.Form("selOpSys")
strName = Request.Form("txtName")
Response.Write "You selected ＇" & strOpSys _
& "＇ for machine ＇" & strName & "＇."
End If
％ 〉
〈 FORM action="pageone.asp" method="post" 〉
Machine Name:
〈 INPUT type="text" name="txtName" 〉
〈 P / 〉
Operating System:
〈 SELECT name="selOpSys" size="1" 〉
〈 OPTION 〉Windows 95〈 /OPTION 〉
〈 OPTION 〉Windows 98〈 /OPTION 〉
〈 OPTION 〉Windows NT4〈 /OPTION 〉
〈 OPTION 〉Windows 2000〈 /OPTION 〉
〈 /SELECT 〉
〈 P / 〉
〈 INPUT type="submit" value="Submit" 〉
〈 /FORM 〉
〈 /BODY 〉
〈 /HTML 〉


尽管这是一个ASP页，(文件扩展名是.asp 而不是 .aspx)，如果我们将扩展名改为.aspx的话，
在ASP＋下是同样工作的。记住这两种系统在同一个机器上是自由并存的，文件的扩展名决定是由
ASP 还是 ASP＋ 来处理。

下图显示在Internet Explorer 5中看起来是什么样的。当用户点击Submit 按钮向服务器传递
值时，页面被重新装载显示选择的值。当然在真正的应用程序中，有些值要储存在数据库中，或者
用来执行一些专用的处理。