网站建设中当开始为.NET编写组件的时候，现行的一些设计准则仍然能够使用。然而，.NET Framework毕竟与COM和COM+组件不同，过去的一些设计原则现在只能以不同的方法来执行。过去根据使用语言的不同，甚至会有不同的准则。现在，在.NET中这些准则得到了统一。使用这些设计准则的另一个关键之处在于，Microsoft在创建系统架构本身，连同SDK中的所有范例时，都已经遵守了这些原则。
CLR环境的特点之一是能够持续有效地对包括结构化异常在内的各种错误进行处理。这个特点对CLR环境支持的所有语言都是有效的，因而应该在任何可能的情况下使用。以前使用错误代码，检验返回值，甚至用On Error Goto语句的方法，已经被捕捉异常，并在异常处进行错误处理的方法所替代。
在过去，如果用一种语言子类编写组件，然后再用另一种语言子类来扩展该组件，这是非常困难的，或者说事实上是几乎不可能的。用C++编写一个类，再用VB来继承它以创建一个新的对象，像这样的事是绝对不可能发生的。如果没有父对象的或者至少头文件的源代码，我们同样也没办法使用一个已编译成二进制的组件（即使这组件是用同一种语言编写的）并从中派生出一个新的对象。
不过，由于有了CLR，我们就可以解决上述问题。与.NET类相关的元数据提供了足够多的信息（甚至是以已编译的形式），使我们可以从现有的类中派生出新类。CLR可以让我们做的另一件事情是一种不同的语言派生一个新类。过去要派生一个新类得拥有基类的源代码才行，而且编写新类所用的语言必须与基类所使用的语言相同。但是现在所有的CLR语言都编译成中间语言，所以用户可以使用任何一种CLR语言派生新类。
Win32体系结构中当前有两个问题，被称之为DLL Hell。在DLL Hell中，没有控件实体负责安装到系统的所有DLL文件。关于COM DLL的信息保存在注册表中，这些信息会很容易地被别的应用程序改写。对于非COM DLL的DLL，在注册表中没有任何对应于它的项。应用程序的安装程序也可以改写已存在的DLL。这样做会严重破坏一些现有的应用程序，这些应用程序调用方法时依靠特定DLL执行具体的函数。
Win32有一个特殊的问题，即在组件间没有系统级的版本规则实现。这个问题只好依靠良好的编程习惯去解决，即一旦发布了接口，它就永远不能再改变了——但在操作系统中又没有什么可以明确预防这一点。另一个问题是应用程序没有一个通用的方式来说明它需要特定组件的版本。只好由开发人员在将DLL调入应用程序前对DLL版本进行检验。如果没有进行检验，应用程序发现了不同的版本，那么它所依靠的代码可能已不存在了，或者说它可能不执行应用程序所期望的函数。为了改变这些情况，windows添加了系统文件保护。这是一个OS功能，能够防止任何的安装程序改写任何系统DLL。
能同时运行同一个组件的多种形式，这是CLR的一个非常有用的功能，它甚至能在同一个进程中执行同一个组件的两种版本。我们把这种功能称之为并排执行。由于该功能的实施，.NET Framework为开发人员提供了由于COM架构的地方。虽然过去也有进行并排执行的方法，但时在.NET中的并排执行却把开发人员从过去的烦琐中解脱了出来。通过在CLR信息通道中对并排执行处理，开发人员只要考虑应用程序中的特定业务代码就行了。
在创建组件的新版本时，开发人员无需因为必须与以前的版本保持兼容而考虑得太多。因为旧版本与新版本一起正常运行，而且使用该组件的应用程序知道该使用组件的哪一种版本，在同一台机器中两种版本可以和平共处。将组件的新版本与以前的版本并排执行，开发人员有几个事项需要注意一下。例如，如果组件依赖一个物理文件作为数据高速缓存，那么并排执行的组件就会视图访问同一个文件。在编写组件时应该注意将文件依据要执行的组件的版本存放在某个位置。在某些情况下，CLR所提供的功能优于COM。现在我们可以从用不同语言编写的类中派生出新对象，即使是我们只有基类的已编译版本也可以做到这一点，所以，这种并排执行的功能给我们编写组件的时候带来极大的方便。
服务器控件能够将其他对象以及基本类型作为特性开放。一个ASP.NET页面中的服务器控件声明能够直接通过两种方式设置某个对象特性的特性值。第一种方法是对属性名使用Object Walker语法，该方法使用连字符（-）来指定一个对象的特性。支持一个对象特性很简单。例如，这个简单的类定义允许使用特性A和B设置两个字符串值。通过使对象特性初始化，服务器控件就能用很少的代码将逻辑关联的属性组合在一起并方便地将它们在一个或多个控件上开放。典型的例子是大多数ASP.NET控件使用的style对象。大多数ASP.NET Web控件都支持该方法。然而，为了是其能够工作，我们需要使用ParseChildren属性指定一个true值来注释我们的服务器控件类定义。
当回送发生并且某个控件有回送数据时，LoadPostData方法就会被调用。该方法为页面上所有需要访问回送数据的控件依次调用。如果控件因为被禁用等原因而没有获得任何回送数据，该方法不被调用。控件即使没有回送数据，也可以通过调用Page.RegisterRequiresPostBack方法，来显示要求调用该方法。
在网站建设编码中当回送发生并且某个控件有回送数据时，LoadPostData方法就会被调用。该方法为页面上所有需要访问回送数据的控件依次调用。如果控件因为被禁用等原因而没有获得任何回送数据，该方法不被调用。控件即使没有回送数据，也可以通过调用Page.RegisterRequiresPostBack方法，来显示要求调用该方法。
在组合控件的生命周期的不同阶段中都可以调用CreateChildControls方法，但只能调用一次，除非我们使用ChildControlsCreated特性显示地重置控件状态，因此它是在控件生命周期发生的不确定事件。而不像Init及Render事件，在页面的生命周期中发生的固定的时间段，而且是确定性的。
如果CreateChildControls方法在执行的过程中未被调用，那么在页面预显示阶段则一定要被调用。如果调用了控件的公有FindControl方法，或者Control自己调用了受保护的EnsureChildControls方法，该方法将在这之前被调用。当回送数据被返回某个控件时，FindControls方法将被调用，所以如果有与某个给定控件相关联的回送数据，在页面的回送阶段CreateChildControls也将被调用。
网站建设中在一个ASP.NET页面被显示出来以后，曾经创建了该页面以及所有的服务器控件的页面对象就被破坏了。当回送发生时，一个新的页面对象和新的服务器控件对象就被创建出来。在编写一个服务器控件时我们常常需要保持和管理状态。因为控件随着每个页面请求被创建，然后被破坏，因此在对象成员变量中存储的状态将丢失。如果一个控件想要保持状态，它就必须用别的方法来做这件事。就像我们在文本框控件中看到的那样，管理状态的方法之一是使用回送。当一个回送发生时，任何与控件相关联的回送数据都经由IPostBackData接口而对控件可用。控件因此可以重新填充它的类变量，使控件保持状态。
作为一个ASP.NET开发人员，我们真正要做的决定是：是让ASP.NET自动为我们建立服务器控件，（仅仅通过使用ASP.NET页面以及（或者）用户控件建立我们的站点），还是由我们自己创建控件。在后一种情况下，我们可以综合使用ASP.NET页面、用户控件以及自定义服务器控件建立我们的站点。所以，为什么要建立服务器控件是没有绝对的答案的。但是我认为主要有一下几点原因供大家参考：
1、ASP.NET控件支持细粒度级别的黑盒复用。ASP.NET用户控件以及页面同样能够提供这项复用功能，但由于它们的粒度要粗糙得多，并且有固定的UI特征（尽管用户控件支持模版，页面却不支持），所以，它们可能提供的复用功能要少得多。
要通过XML和HTTP解决显示应用程序逻辑或细节信息的问题并不困难。过去，我们使用诸如ASP、JAVA或Perl这样的语言编写一个简单的应用程序，此程序可以通过XML显示数据。例如，可以使用ASP编写简单的应用程序，接受查询字符串的值，并生成代表具体数据库表的XML返回文档。应用程序可以简单地调用终点（比如，显示数据库表的URL），并从文档中获取、分析和派生值。
但是这种设计方式是与其他因素紧密联系的。客户机希望得到高度结构化的XML文档，如果提供这种文档的应用程序发生了变化，则客户机实现就很有可能中断。在大多数情况下，可以通过使用公共XML模式解决这个问题，但是为不同的应用程序分别维护和管理不同的模式国语麻烦。而且，XML文档还依赖于服务器的实现方式。
