很多技术人员已经在像JSP这样的技术上从事了大量的工作，从而将面向对象（OO）的设计和原理带到了Web开发里。但是在我看来，ASP.NET走得更远，它将这些原理带给了并非从事编程工作的Web开发人员。例如在ASP.NET里，Web开发人员并不需要了解某一门特定语言的细节或者运行的架构。相反，这些开发人员能够选择在服务器端所使用的语言，包括ECMAScript（或者按照微软的术语，JScript.NET）。针对非编程人员的面向对象的设计是通过ASP.NET的用户控件（User
Control）来实现的。
ASP.NET的用户控件（也叫做“pagelets”），是作为一种封装了特定功能和行为（这两者要被用在Web应用程序的各种页面上）的Web页面被开发的。一个用户控件包含了HTML、代码和其他Web或者用户控件的组合，并在Web服务器上以自己的文件格式保存，其扩展名是*.ascx。ASP.NET里的缺省配置并不允许Web客户端通过URL来访问这些文件，但是这个网站的其他页面可以集成这些文件里所包含的功能。要实现这一点，就要把对用户控件的参照放到可访问页面顶部的指令（directive）里，然后你就可以像使用Web控件一样在页面的任何地方使用这些控件。见下面的例子：
<%@ Register TagPrefix="MyControls"TagName="ProductItemDisplay"
Src="ProdItem.ascx" %>
...
<MyControls:ProductItemDisplayid="item1"
runat="server"
name="Widget"
price="19.95" />
...
<MyControls:ProductItemDisplayid="item2"
runat="server"
name="FooBar"
price="29.95" />
这一概念和服务器端包含（include）的概念不一样，其不同点在于：放在页面上的每个用户控件都存在于自己的命名空间里。任何尝试要在传统的ASP页面上多次使用服务器端包含（后者含有服务器的脚本块）的人，都会立即看到命名空间的好处。如果你已经尝试过，那么就很容易看到，传统的ASP页面会因为重新定义的变量和脚本过程而产生一个编译错误。在使用用户控件进行开发的过程中，由于控件的每个实例都存在于页面上一个唯一的命名空间里，因此用在用户空间里的变量名和过程名不会相互发生冲突，因而不用去考虑一个页面上有多少实例。每个用户控件的代码和功能都可通过控件的特定实例来访问。在上面的例子里，（假设ProdItem.ascx文件已经定义了一个“Buy”方法），你应该使用和下面代码段类似的什么东西来为Widget物品的购买进程进行初始化：
item1.Buy()
用户控件，就像普通ASP.NET的Web表单页面一样，能够使用代码分离的文件把*.ascx文件的表示逻辑同控件的功能分离开来，后者可以使用任何支持.NET的语言来编写。这样一种安排方法能够有助于将设计人员和编程人员的职责分离开来，让设计人员主要负责查看和感受控件的好处，让编程人员来开发必要的功能。无论是代码分离还是*.ascx文件自己内部的脚本块，都能够将其功能（属性和方法）向Web表单页面的设计人员公开。
事实上，几乎所有的Web网站都能够从用户控件里获益，因为这些网站一般都会将常见的元素在不同的页面里多次使用，例如广告横幅、工具条、法律声明和版权声明等。
