问：自从在七月份的专业开发者大会（Professional Developers Conference，简称PDC）上，我已经听到有关ASP+服务端控件的消息，他们和ActiveX控件相比，有什么不同之处？为什么我要经常使用他们？
答：这是一个很好的问题。所有来自微软的新技术，他们总是很难让人弄明白。服务端控件是一种自定义控件。你也许会想，自定义控件已经存在于我们的身边了，不是吗？在90年代的VBXs，1994年的OLE控件，和1996年的ActiveX控件。一个很主要的因素是他们都是基于客户端的控件，服务端控件的不同之处就在于他们存在于服务器端。当你可以只建立控件在客户端的时候，为什么要建立控件在服务端呢？
浏览器扩展的问题
问题就在于客户端控件丰富用户接口上：浏览器必须提供技术去扩展它。举个例子来说，如果你希望浏览器使用一个ActiveX控件影响站点，那么浏览器必须提供ActiveX控件的支持。那么浏览器就需要一些COM接口，同样的，任何站点使用JAVA语言的APPLET小程序也希望浏览器支持他们。
希望用户使用最新版本的具有特殊功能的浏览器是不切实际的。并且浏览者并不只是只有客户端；今天，人们使用WAP电话，WIN CE驱动的设备，和掌机。如果你使用JAVA语言的APPLET小程序或者是ActiveX控件对你的站点作必要的操作，你将不能延伸你的客户群，因为他们得不到支持。
这进对两难的局面，在ASP+中得到了答案－那就是把转换的责任都推倒服务器的身上。
服务端的转换
准确的说，每一个浏览器都可以解释和显示HRML文档。如果你不能扩展浏览器的用户接口，为什么不让服务器根据用户定制的界面返回给用户一个相应的HTML文档呢？微软称之为自定义表单控件或者服务端控件。
当然，你可以总是为一个丰富的用户接口编写HTML代码，或者是在ASP中编程。微软赋予你的是一个可以在服务端创造丰富的用户接口的一个已定制的框架和协议。
表单控件是独立于WEB页面以至于你可以在页面中创建，修改和维护个别的表单控件。在表单控件的公共的字段，属性，和方法可以很方便的访问容器中的控件或是页面。除此之外，表单控件是分等级的；他们可以继承，包含和扩展其他的控件。简而言之，在达到非常宽范围的客户群的开发时，使用表单控件帮助促进基于组件的开发是非常容易的。
表单控件是在即将来临的ASP+框架中设计工作的组件，他们继承于写于.NET公共语言运行时目标语言，以至于在ASP+运行时拥有HOOK钩子，当ASP+分析一个WEB页面时，ASP+ Runtime会遇到这些控件中的一个。当ASP没有遇到控件时，ASP+ Runtime会创建和初始化它。就像ActiveX控件，ASP+服务端控件提供属性，方法和事件。这些组件，不像ActiveX控件，独自生存在服务器中。他们永远不会被下载到客户端中去。
在探讨这些新的服务端控件之前，让我们看一下ASP和ASP+，因为只有懂得他们之间得不同，才会了解服务端控件时如何工作得。
ASP Vs ASP+
在过去的几年中，ASP是在所有浏览器中产生HTML文档十分有用的方法。ASP的执行模式是一个可爱的直线型。当你建立一个ASP脚本，ASP Runtime简单的执行这个脚本。在它良好工作的同时，它比较慢，并且有其他使用脚本上的缺点。相比之下，ASP+分析ASP文本并且执行一个经过.NET运行时语言验证过的页面类。这个类是一个时间驱动的模型，并且为客户端的一段翻译输出流（产生的HTML）。
ASP+定义了两种类型的表单控件－Pagelet控件和precompiled控件，Pagelet控件是纯的HTML文本，标记和可能的其他HTML控件（按钮，文本控件，和其他）。Pagelet控件在需要时编译（就像其他在ASP+页面中的例子），Precompiled控件写于一种语言，并且它的目标是公共语言运行时（CLR），他们被编译进DLL里。现在，这些语言包括C#，托管的C++，和微软的VB.NET，其他的语言也会被支持，我将焦点集中在Precompiled控件。
服务端控件
有一些引人注目的理由去使用自定义服务端控件，除了让它创造丰富的便于用户使用的WEB应用程序接口，你也可以使用控件划分代码和内容。这个ASP+的模型让我们从执行的代码中分离了HTML。使用这个分离的逻辑，每个部分可以独立的开发。
最后，服务器控件使应用程序编程模型简单化。在自定义控件里利用功能性的压缩，网页开发者可以利用控件属性和相应时间来使用他们。
了解服务端控件的最重要的部分是他们的存在是使用专门的控件变得容易。一旦你了解他们背后的原理，其余的就需要技巧了。写一个控件，你需要懂得一些ASP+，HTML，和一些C++（或者是C#，或是VB.NET）的语法。我将第一个考虑通过C#的类建立一个控件的体系结构，然后考虑一个相似的控件使用VB.NET语法。
一个简单的控件
在.NET平台下，代码在ASP+下运行必须符合CLR的规则。现在，CLR能处理的语言包括C#，Visual Basic.NET，和托管的C++，描述1展现了一个由C#创建的十分简单的控件，它的作用是在任何一个地方的浏览器里输出简单的HTML格式的字符串。
这是一个你创建的漂亮的并且是一个十分简单的控件，它完全并且可以编译进一个工作的DLL中。在描述1中有一些十分值得注意的地方，包括命名空间，C#语法，和函数，让我们一个一个来看。
命名空间：代替了C++的包含头文件，C#使用命名控件。命名空间从中心和外表上利用集中有联系的类，接口，结构和枚举，并且还有委托把C#程序组织起来。Using指示符告诉C#程序使用哪个命名空间。一个服务端控件的命名控件包括System，System.Web，System.Web.UI，System.Web.UI.Control。
System命名空间包括像类激活和序列化之类的系统服务，System.Web命名控件包括原始的Web系统服务，像HTTP管理。System.Web.UI命名空间组织像控件管理和HTML CSS管理服务。最后System.Web.UI.Control命名空间包括用于建立控件类定义的类。
控件类：控件类定义了在ASP+页面控件中所有的服务端控件的公共的属性，方法和事件。C#支持继承，就像C++，所以控件的开发得自类和虚拟函数的使用。然而，在C#中，这些函数叫做overridable函数（C#包含一个关键字，override，强制执行当前类的函数的版本）。控件类包含了基本的构造来支持在.NET中的服务端控件。
在WEB页面上使用控件
在ASP+中使用控件的语法是很直接的。接下来的代码展现了载入了一个十分简单的ASP+页面。
<%@ Register TagPrefix="MSDN" Namespace="MSDNSamples" %>
在这个ASP+页面的第一行中描述了一个名为MSDN的标记，它是MSDNSample命名空间的别名。（返回到C#例子并看一下最顶端的命名空间的定义）。ASP＋页面简单的涉及到控件DLL的命名。注意runat=”server”属性，它指示了SimpleCtl是一个服务端控件。记住ASP+的任务是翻译并在浏览器输出一些HTML。这个页面首先输出html和body标记。然后进入空间函数的输出。最后body和html标记是关闭标记并结束页面。
为了测试这个页面，只要把他们放到服务器上并使用HTTP协议访问。你使用的目录必须是一个在IIS下的虚拟目录。使用程序－管理工具－计算机管理MMC snap-in建立一个虚拟目录并包含ASP+的代码文件。你可以设置你想要的任意的输出流并且它将会显示在浏览器上。我将会着眼于更丰富的控件将来的专栏中。
除了使用C#，你还可以使用VB.NET来写服务器控件，语法也非常相似；描述2展现了一下相似的由VB.NET写的控件。
注意VB.NET的代码同C#一样，同样导入命名空间。VB.NET的代码定义了一个从控件继承来的类并且覆盖了Render方法。这些代码将会编译进一个DLL文件并且当它作为服务器控件被插入到浏览中的时候会显示字符串“What’s up in Visual Basic?”。
结束
这是一片对于微软即将来临的服务端控件的高级教程。当然，我没有暗示ActiveX控件会远离我们而去。但是它让我们看到了他们会在开发中以一种不同的角色出现。你可以注意到在一定的客户端环境里ActiveX控件非常的重要。ActiveX控件表现了将像图表和唯一的控件装入用户接口的极好的方式。然而，当你不知道你的客户应用你的程序是采用哪种客户端的时候，ASP+服务端控件通常是种好的选择。
在接下来的专栏，我将探讨更多丰富的控件。我将会调查更多高级方面的问题像服务端控件视图状态的管理和处理提交返回。
译文部分
译文部分
附录A 外文翻译原文--Server-side Controls in Active Server Pages+
George Shepherd
Q:Ever since the PDC in July I've been hearing about Active Server Pages+ (ASP+) server-side controls. What are they, and how are they different from ActiveX® controls? Why would I ever use one?
Web Andrews
A:That's a good question. With all the new technology coming from Microsoft, it's sometimes hard to keep everything straight.
Server-side controls are custom controls. You're probably thinking that custom controls have been around forever, right? There were VBXs in the early 90s, OLE Controls in 1994, and ActiveX controls in 1996. One main characteristic of these controls is that they reside on the client. Server-side controls are different because they live on the server. Why would you want to create controls to hang out on the server when you could simply build client-side controls?
The Problem of Extending the Browser
Here's the problem with using client-side controls to enrich the user interface: a browser has to support the technology to extend it. For example, if you want the browser to use an ActiveX control to interact with the site, that browser must support ActiveX controls. The browser requires a handful of COM interfaces for this. Likewise, any Web site using Java-language applets expects browsers to support them.
It's unrealistic to expect everybody to use the very latest version of a particular browser. And browsers aren't the only clients to consider; today people use WAP phones, Windows® CE-powered machines, and handheld devices. If you make Java-language applets or ActiveX controls essential to the operation of your Web site, you won't be able to reach clients that don't support them.
In ASP+ there's an answer to this dilemma—move the responsibility of rendering to the server.
Server-side Rendering
By definition, every browser can parse and display HTML. If you can't enrich the user interface by extending the browser, why not have the server pump out the right kind of HTML to give a customized appearance to the user? Microsoft calls these custom controls Web Form controls or server-side controls.
Sure, you can always handcode the HTML for a rich user interface, or program it into your ASP page. What Microsoft brings to the table is an established framework and protocol for generating a rich UI from the server.
Web Form controls are independent of the Web pages that use them and can be created, modified, and maintained separately from the pages. The public fields, properties, and methods of a Web Form control can be accessed programmatically by the containing control or page. In addition, Web Form controls are hierarchical; they can inherit from, contain, and extend other controls. In short, Web Form controls help promote component-based Web development while at the same time making it easier to reach a much wider range of client devices.
Web Form controls are components designed to work within the upcoming ASP+ framework. They're implemented within DLLs written in a .NET common language runtime-targeted language that has the hooks expected by the ASP+ runtime. As ASP+ parses a Web page, the ASP+ runtime may encounter one of these controls. When ASP does encounter a control, the ASP+ runtime creates and initializes it. Like ActiveX controls, ASP+ server-side controls expose properties, methods, and events. However, these components, unlike ActiveX controls, live solely on the server. They are never downloaded to the client.
Before dissecting the workings of these new server-side controls, let's take a high-level look at ASP and ASP+, because understanding the difference is important for understanding how server-side controls work.
ASP Versus ASP+
For the past few years, ASP has evolved into a very useful means for generating HTML that is compatible with all types of browsers. The ASP execution model is pretty linear. When you set up an ASP script, the ASP runtime simply executes the script. While this works fine, it is slower than it could be and has other disadvantages associated with scripting. By contrast, ASP+ parses the ASP text and generates for execution a standard page class recognized by the .NET common language runtime. The class has an event-based execution model, and rendering the output stream (the generated HTML, for example) to the client is one phase of the Page execution.
ASP+ defines two types of Web Form controls—pagelet controls and precompiled controls. Pagelet controls are composed of HTML text, tags, and possibly other HTML controls (buttons, text controls, and so forth). Pagelet controls are compiled on demand (as is the case with any other ASP+ page). Precompiled controls are written in a language that targets the common language runtime (CLR) and are compiled into DLLs. Right now, these languages include C#, the Managed Extensions for C++, and Microsoft® Visual Basic .NET. Other languages from other vendors are sure to follow. I'll focus on precompiled controls here.
Server-side Controls
There are several compelling reasons to use a custom server-side control. In addition to making the rich user interface of your Web application useable in any number of client situations, you can use controls to partition your application into code and content. The programming model in ASP+ lets you separate HTML from executable code. By separating the presentation from the logic, each part may be developed independently of the other.
Server-side controls represent a great opportunity for encapsulating reusable code, and they can be completely self-contained. That way, a page developer can drop an HTML tag onto a page.
Finally, server-side controls simplify the application programming model. By encapsulating functionality in a custom control, page developers can use it by setting control properties and responding to events.
The biggest part of understanding server-side controls is realizing that they exist to make it easier to manage specialized controls. Once you see the motivation behind them, the rest is mostly mechanics. To write a control, you should understand a little about ASP+, HTML, and a bit of C++ (or C#, or Visual Basic®) syntax. I'll look at the control architecture first through a C# class, then look at a similar control using Visual Basic syntax.
A Simple Control
Under the .NET platform, code running under ASP+ must adhere to the CLR specifications. Right now, languages that target the CLR include C#, Visual Basic .NET, and the Managed Extensions to C++. Figure 1 shows a very simple control written in C#, whose job is to write a simple HTML-formatted string to a browser out on the Internet somewhere.
While this is pretty much the simplest control you can create, it is complete and will compile into a working DLL. There are several notable aspects of the code in Figure 1, including the namespaces, the C# syntax, and the Render function. Let's take a look at each.
Namespaces Instead of including header files as C++ does, C# uses namespaces. Namespaces organize C# programs, both internally and externally, by collecting related classes, interfaces, structures, enumerations, and delegates. The using directive tells the C# program which namespaces to use. The namespaces required by a server-side control include System, System.Web, System.Web.UI, and System.Web.UI.WebControls.
The System namespace includes system services such as class activation and serialization. The System.Web namespace includes Web-oriented system services like HTTP management. The System.Web.UI namespace organizes services like control management and HTML cascading style sheet management. Finally, the System.Web.UI.Control namespace includes the definition of the Control class for building the control.
The Control Class The Control class defines the properties, methods, and events common to all server controls in the ASP+ Page framework. C# supports implementation inheritance, just like C++, so control development involves deriving from a class and tweaking the virtual functions. However, with C# these functions are called overridable functions (C# includes a keyword, override, to enforce the calling of the correct version of the function). The Control class includes the necessary infrastructure to support server-side controls within the .NET platform. For this discussion, the important function to look at is called Render.
Server-side Control Rendering The information you put into your control's Render method defines what the control will look like. Render takes a single argument of type HtmlTextWriter. HtmlTextWriter abstracts the details of streaming HTML content to the browser level. HtmlTextWriter has a host of member functions for doing this. The one that appears in Figure 1 is WriteLine, which takes a C# string and sends it to the browser. Other functions within HtmlTextWriter include methods like WriteLineNoTabs, WriteBeginTag, and WriteEndTag.