(怡红公子)
1)为什么我们需要一个新版本的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#. 都可用。而你也可以确信第三方的工具制造商也不会落后太多。
2)ASP＋ 如何使生活更简单？
目前Web 开发人员面临的最大挑战是浏览器的兼容性问题和他们所要创建的网页的复杂程度不断增加。要创建更加交互式的页面，又要利用各种浏览器的最新特色的，同时还要确定页面在所有可能的浏览器上都能工作，简直是挥之不去的噩梦。
当然，使用这些正在兴起或已经在使用的新Internet 设备会使情况更糟糕。特别是，要创建的网页对移动电话和传统浏览器客户提供相同用户级别的兼容性也成为可能。只能显示3行字符文本的移动电话当然要限制创造性和用户交互性。
一个显然的解决办法是创建动态定位每个特定客户的输出？还是创建同一站点的多种版本，每个客户一种版本。第二种方法可不诱人，许多人更倾向于第一种。但是这就意味着来自于每个用户的每一次敲击都需要一些服务器侧的处理来指明创建哪种输出。
如果是这样，为什么不让这一过程自动化？到这，ASP＋ 介绍了服务器控制的概念，其中包含普通任务和提供一个清楚的编程模型。它们还帮助处理对各种不同类型客户的定位。
3)写较少的代码进行服务器端HTML控制
ASP已经提供了在服务器上运行组件的机会，这些组件产生返回给用户的页面部分。ASP＋ 通过服务器控制扩展了这一概念。将任何HTML元素转换成服务器控制所需要做的只是增加一个额外的属性: runat="server"。
一页中的任何HTML元素都可以用这种方法做标记，然后ASP＋ 就在服务器上处理这些元素，然后产生适合这一特定服务器的输出。另外作为副产品，我们还可以特别创造一个额外的小窍门，用HTML
尽管这是一个ASP页，(文件扩展名是.asp 而不是 .aspx)，如果我们将扩展名改为.aspx的话，在ASP＋下是同样工作的。记住这两种系统在同一个机器上是自由并存的，文件的扩展名决定是由ASP 还是 ASP＋ 来处理。
在Internet Explorer 5中当用户点击Submit 按钮向服务器传递值时，页面被重新装载显示选择的值。当然在真正的应用程序中，有些值要储存在数据库中，或者用来执行一些专用的处理。在例子中我们只是在页面上显示。
一个问题是页面不维护它的状态，换句话说控制返回它们的默认值。用户要再次使用表达就要重新输入。要避免这种情况，就需要在页面上增加一些额外的代码，当页面重新装载时将值插入控制中。对文本框来说只是用内联ASP代码设置value 属性，用HTMLEncode 方法确保任何不合法的HTML字符都被适当编码。但是对于
当页面重新装载时，控制维护它们的状态并显示用户所选择的值。
5)自动维护状态的控制
在通常遇到的情况下，ASP＋ 如何帮助我们？下面的清单显示利用ASP＋ 服务器控制自动状态所需要的改变。还是使用Response.Write 方法显示选中的值。但是这次页面上的有些元素要增加一个特殊的runat="server" 属性。ASP＋ 看到这些元素，就在服务器上处理它们并且为客户创建适当的HTML输出。
你可以清楚地看出这个ASP＋ 页比上一个例子要简单。当载入Internet Explorer 5 并将值提交给服务器时，出现的结果是一样的。
6)服务器端的控制如何工作？
这是如何实现的？关键是runat="server" 属性。要了解这是如何进行的，看看浏览器内页面的源代码。是这样的：
You selected ＇Windows 98＇ for machine ＇tizzy＇.
用这个ASP＋ 代码创建
当页面被ASP＋执行时，到浏览器的输出是：
可以看到action 和 method 属性是ASP＋自动创建的，所以表单中控制的值就会被邮递回同一页。ASP＋还为表单增加唯一的id 和 name 属性，因为我们没有提供。但是如果你确实指定了这些属性，就会使用你所指定的值。
如果包含了method="GET" 属性，表单的内容就作为查询字符串的一部分被发送给服务器，同以前版本的ASP一样，自动状态管理就不再有效。
在表单内，用这样的ASP＋ 代码创建文本框：
浏览器的结果是这样的：
可以看到当表单被提交时，ASP＋以控制中的文本值自动增加了value 属性。它还保留了我们提供的name 属性，还以同样的值增加了一个id属性。
我们为
