介绍

ASP.NET MVC 框架直接映射URL到他们所引用的控制器类中。控制器处理引入的请求，用户的输入和交互，以及执行相应的应用程式和数据逻辑。一个典型的控制器，会呼叫一个分离开的视图为请求生成HTML标记。

注意：
要运行以下代码，你需要ASP.NET 3.5 Extensions预览版。你可以从 ASP.NET Web site中下载。

ASP.NET为了MVC开发提供了以下类型

1.  IController - 控制器的协议接口
2.  Controller - 提供一般MVC处理的控制器基类

控制器基类有以下职责：

 1、指向对应的方法，以及验证是否有权呼叫
 2、获取操作方法所需要的参数
 3、执行操作方法期间，处理所有异常。
 4、为呈现ASP.NET页面（视图）提供默认的WebFormViewFactory。

注意：
为了安全访问各种各样的控制器和控制器的操作，你可以使用PrincipalPermissionAttribute。

以下是一个控制器类的例子。控制器类包含操作方法，操作方法的参数和呈现视图的方法。

操作方法（Action Methods）

控制器定义许多操作方法。默认情况下，操作方法与用户的交互拥有一对一的关系。用户的交互距离包括使用URL进入浏览器，点击链接，以及提交表单。这些每个用户交互会产生出一个请求，发送到服务器。在每个情况中，请求的URL都包含MVC框架需要调用操作方法的信息。

举例，当用户输入URL到浏览器，MVC应用程式中定义在Global.asax的用户导航规则会分析URL，决定通往哪个控制器。然后，控制器就会定位适当的方法去处理请求。控制器包裹很多所需要的操作方法。

在没有使用MVC框架的ASP.NET应用程式中，用户的交互都集中在页面，以及触发、处理来自页面的事件。相反，在ASP.NET MVC应用程式中，用户交互集中在控制器和他们的操作方法。

默认情况下，一个请求的URL被解释的字路径包括操作名字的控制器的名称。举例，如果用户输入URL“http://contoso.com/MyWebSite/Products/Categories”，子路径为“/Products/Categories”。默认的导航规则认为“Categories”为操作的名称，以及Products控制器将会调用Categories方法处理请求。如果URL以“/Products/Detail/5”结尾，默认的导航规则认为“Detail”为操作的名称，以及Products控制器将会调用Detail方法处理请求。在URL中的5将会当Detail 方法参数传入。

以下例子展示控制器和控制方法：

所有的控制器类命名必须以Controller结尾，以及控制器的类必须继承于Controller基类。

操作方法参数

默认情况下，操作方法的参数是来自Request的数据集合。数据集合包括“键-值”数据，包括表单数据，查询字符串、cookie值等。

基于RouteData实例和表单数据，控制器基类定位所要操作的方法，如果方法包括参数，控制器基类会为方法决定相关的参数值。如果参数没有被解析出来，并且同时参数的类型是引用类型或者空的允许空的值类型，null就会被当参数传入。否则，抛出异常。TypeConverter通常用于从URL或表单数据参数中，转换正确的参数类型。

在控制器类的操作类中，有几种方法可以访问URL的参数。控制器的基类有一套可在操作方法方法的公开属性对象“Request”和“Response”。这些对象模拟在ASP.NET已有的 HttpRequest 和 HttpResponse 。然而，一个重要的不同点在于，控制器类的Request和Response对象是继承System.Web.IHttpRequest 和 System.Web.IHttpResponse ，代替以往的封闭类。这个接口可以更方便的创建mock对象，更方便对控制器做单元测试。

以下的例子展示如何在Detail方法内，使用Request对象获取查询字符串名为“id”的值。

自动映射操作方法参数

ASP.NET MVC 框架可以为操作方法自动映射URL参数到方法的参数值。默认情况下，如果一个操作方法需要参数，MVC框架会检查请求的数据和决定HTTP请求值中是否有相同参数名称值。如果有，请求值自动会传入到操作方法。

下面的示例是上面例子的变体。在这个变体中，id参数被认为映射到请求的URL也名为id的数据。由于自动的映射，方法中无需拥有任何从Request获取参数的代码，因此代码更简洁。

你也可以使用内嵌参数值到URL中，代替以往的查询字符串用法。举例，以往使用查询字符串链接的URL如“/Products/Detail?id=3”，你可以使用类似以下的URL“ /Products/Detail/3”代替。

默认的导航映射规则格式为/[controller]/[action]/[id]。如果URL的子路径后面接着控制器和操作方法的名称，那么参数的名称就被认为id，它会自动传入操作方法做参数。

MVC框架对方法参数允许可选的参数。在MVC内的可选参数，被处理为可空类型，示例，如果你有一个方法需要一个日期的查询字符串，但你想如果参数为空的时候默认为今天的日期，你可以使用以下的代码：

如果请求中包含date的参数，那么就会传递到ShowArticles 方法内。如果请求中没有包括参数值，参数将会为null，控制器无论如何也需要处理这个缺省值。

处理未知方法

控制器基类调用HandleUnknownAction处理了一般情况下的未知方法。默认，方法会返回HTTP 404 状态。

你可以为配置默认的一个方法，处理任何不予实际动作方法通讯的URL。以下例子说明一种方法，重写HandleUnknownError方法，重定向到搜索页。

在ASP.NET应用程式，引入的URL请求一般都会直接映射到.aspx文件。一个不使用URL重写的标准ASP.NET应用程式，一个“ /InterestingNews.aspx”的请求将会映射到物理文件“InterestingNews.aspx”，其包含的代码和标记就会输出浏览器相应的响应。

ASP.NET MVC框架包括一个URL导航引擎，它可以映射引入的请求到控制器的类和动作（动作部分通常是需要的，但并不是必要，它协作于控制器类的方法）。URL导航引擎可以分析你在URL所定义的变量，自动以方法参数的形式传入控制器的动作。

ASP.NET MVC 模板在Global.asax文件的Application类包含了一个预先配置好的URL导航规则。这默认的配置能让你无需为你的程序显示配置导航规则就可以开始编写ASP.NET MVC 应用程式。换句话说，你可以使用默认的命名URL映射协定。

默认的命名URL映射协定

默认的命名协定映射引入的HTTP请求的URL路径的一部分到对应的控制器。映射是基于URL对应的控制器名为“UrlPathController”。举例，一个URL包含路径“/Products/”映射的控制器名为“ProductsController”。

控制器类必须实现System.Web.MVC.IController接口，且名称必须以“Controller”结尾。最简单实现控制器的方法就是创建一个继承于System.Web.MVC.Controller的类。你可以向控制器添加方法，方法要标记上ControllerAction特性，让默认的URL导航处理器能调用到对应的方法。如果你遵循这些规则，你就能让MVC框架运行URL导航，以及选择公开你标记了特性的行为方法。

当控制器和导航规则被定义后，ASP.NET MVC框架执行控制器的类，去处理全部以控制器类名称开头的URL请求。如“/Products/”URL。默认的，一个向服务器的请求大致类似以下这种形式：

http://site/application/controller/action[parameters]note

这里所描述的URL导航是为新的ASP.NET MVC应用程式提供的一种默认的模式。当然，你也可以使用不同的模式，创建自定义的URL导航。

如果需要的话，控制器可以调用基于控制器URL的其他部分，如/Products/Categories, /Products/List/Beverages, 和/Products/Detail/3。

请求导航是通过UrlRoutingModule和MvcHandler的HTTP处理实现的。MvcHandler决定哪个控制器被调用。URL的行为部分表示控制器哪个方法被呼叫。行为与业务逻辑合并执行模型的交互。这些行为的结果会被指定的视图所呈现。

URL到控制器的映射

ASP.NET MVC框架使用的默认规则映射控制器和URL，规则包括、行为的名称以及任何行为的参数。以下例子演示URL的语法：

http://domain/site/controller-name/action-method-name?parameters

http://domain/site/controller-name.mvc/action-method-name?parameters

注意：
在IIS6.0中，.mvc扩展名是必需的。

下面的例子展示一个具体的URL到控制器的映射：

http://www.contoso.com/Shopping/Store/ShowCategory?id=5

一些开发者喜欢更加易读的URL语法，如下所示：
http://www.contoso.com/Shopping/Store/beverages/

ASP.NET MVC 框架允许你定义不同的映射设计和自定义URL语法。你可以为你的程式做一个映射设计，定义更有意义的URL，令他支持不同的搜索引擎模型。

举例，在默认的URL映射的情况，下面的URL应该执行ShowCategory方法且附带的参数为5，然后获取Northwind数据库显示Beverages目录。

http://www.contoso.com/Shopping/Store/ShowCategory?id=5

一个自定义的架构可以使用以下URL定制语法，提供相同的数据呈现：
http://www.contoso.com/Shopping/Store/products/beverages

定义RouteTable, Routes, 和 RouteData

你可以在Global.asax文件的Application_Start时间内定义URL导航的映射。下面的例子演示了一般Global.asax文件包括添加到RouteTable对象的Route对象实例。

RouteTable公开Routes collection，包含Route对象集合。每次MvcModule的请求都会执行RouteTable。MvcModule 对象查询每一个在集合中的Route对象，查看URL是否有符合Route对象的映射。

注意
映射的逻辑定义在MvcModule，并且不可自定义。

当URL找到相应的Route映射时，Route就会产生一个IRouteHandler实例。IRouteHandler 实例定义了Route的HTTP Handler。这个Route 处理为请求创建了IHttpHandler 。IRouteHandler 的执行方法被呼叫，并设置到当前的上下文。

如果没有导航相对应，RouteTable 中没有定义相应的Route 。相应处理就直接指向ASP.NET page, Web service, 或其他ASP.NET 终端。

Route 在Routes 集合中的排序是有意义的。Route 对应搜索是从第一个到最后一个的顺序查询。当对应的Route 找到之后，搜索就会停止。默认的route一般放在最后面。

对于IIS7.0,不需要后缀名。下面的代码例子展示创建一个没有后缀名的URL控制器映射的RouteTable 集合。

对于IIS 6.0，URL的名称必须包含mvc的后缀名。下面的代码例子展示创建有后缀名的URL控制器映射的RouteTable 集合。

基于前文所提的URL，以下与其对应RouteData所通讯的值。

URL	RouteData object values
/domain/site/blog	Controller="blog", action="Index", id=null
/domain/site/blog/ShowPosts	Controller="blog", action="ShowPosts", id=null
/domain/site/blog/ShowPosts/123	Controller="blog", action="ShowPosts", id="123"

当route找到对应时，UrlRoutingModule产生以“键-值”成对地产生以上数据RouteData实例。。

如果引入的URL没有route对应，相应处理就直接指向ASP.NET page, Web service, 或其他ASP.NET 终端。

模型-视图-控制器架构模式把一个应用程式分离成三个主要组件：模型、视图和控制器。ASP.NET MVC框架为ASP.NET使用Web-Forms模式开发基于MVC的网页应用程序提供了一个选择。ASP.NET MVC 框架是一个轻量级；表现层框架提供高度可测试；以及（像现在的基于Web-Froms的应用程式）整合了ASP.NET的现有特性，如Master Pages和基于Membership的验证。MVC 框架被定义在System.Web.Mvc命名空间，他的基础部分建立在System.Web 命名空间中。

MVC是一个许多开发者都非常熟悉的标准设计模式。某些类型的网页应用程式将会从MVC框架获取好处。其他的可以继续使用传统的基于WebForms和postback的ASP.NET应用程式模式。也有结合两种框架的Web程式，当然也有两者都不使用的。

MVC框架不使用ViewState和Forms。对于页面重视控件展现多于行为的应用程式，提供了一个理想的方案。

另一方面，基于表单的应用程式支持事件模型，在HTTP协议上可以保持状态，对于开发网页应用程式是非常有好处的。基于网页表单的应用程式提供了许多时间来支持许许多多的服务器控件。MVC使用Front Controller模式，使你在设计应用程式的时候可以完全分离表现层、业务逻辑以及数据访问，使控件按流程支持丰富的架构。网页表单程式使用 page-controller 模式，为个别页面分别添加功能。这两种可以按需混合使用。

MVC组件如下：

 1、Models - Model对象是应用程式负责实现领域逻辑的部分。通常，Model对象可以在数据库获取或存储Model状态。举例，Product 对象从数据库获取信息，操作后，写入更新后的信息到SQL数据库的Products表。

 注意：在一些更小型的程式来说，model通常是是概念上分离多于物理上的分离。举例，如果程式只是读取DataSet，并把它传送到view，程式并没有物理上的Model层和所关联的类。这种情况下，DataSet就担当着Model的角色。

 2、Views - 视图是专职表现程式用户界面(UI)的组建。典型地说，UI从Model数据创建出来的。举例，现在有一个修改Products表的页面，它是根据当前Product对象的状态显示对应的文本框(textbox)、下拉框(dropdowlist)和勾选框(checkbox)。

 3、Controllers - 控制器是负责用户交互，维护Model以及最终选择哪一个view去呈现数据UI的组件。在MVC应用程式中，视图只显示信息，控制器负责处理和回应用户的输入和交互。举例，控制器处理查询字符串(query-string )的值，传递这些值给model，然后就可以使用这些值实现轮流查询数据库。

MVC框架助你创建各个分离层的应用程式（输入逻辑、业务逻辑和UI逻辑），同时为各个元素提供了解耦。这种模式具体指定每一类的逻辑应该存在程式的哪里。UI逻辑是属于视图的。输入逻辑属于控制器。业务逻辑属于模型的。这样的分离有助于你管理建立复杂的应用程式，因为可以让你在一个时间内只关注程式的某一部分的实现。举例，你完全可以只关注视图而无需依靠业务层。

在管理复杂程式方面，MVC模式比传统的ASP.NET网页应用程式提供了更容易测试的程式。举例，在传统的ASP.NET网页应用程式，一个类就负责输出和输入两部分。编写传统ASP.NET网页应用程式的自动化测试是非常复杂的，因为要测试一个页面，你必须实例化一个页面的类和它的全部子控件，以及应用程式中所依赖的所有类。因为运行一个页面都需要许多类初始化，编写程式其中一部分的单独测试代码是非常困难的。而且，测试传统ASP.NET网页应用程式需要Web服务器。MVC 框架为组件和沉重的UI解耦，这样就有可能从框架其他部分分别为各组件进行测试。

解耦了MVC三个主要组件也促进了平行开发。举例，一个开发人员在view开发，第二个可同时在控制器业务层开发，第三个就关注业务逻辑模型。

ASP.NET MVC框架特性

ASP.NET MVC 框架提供以下特性：

1、分离程式的任务（输入逻辑、业务逻辑以及UI逻辑），可测试，以及默认测试驱动开发模式。在MVC框架内，所有核心协议都基于接口，便于使用mock数据进行测试。 你可以在ASP.NET进程中不运行控制器的情况下，进行快速和灵活的单元测试。你可以使用任何一个兼容.NET框架的单元测试框架。

2、框架具有扩展性和可插拔性。ASP.NET MVC 组件非常容易被替代或自定义。你可以组装你自定义的视图引擎，URL转向规则，action方法参数序列化，以及其它组件。ASP.NET MVC 框架提供了现成的依赖注入和IOC容器模型。

3、强大的URL映射，为你的应用程式提供通熟易懂、可搜索的链接。链接不必一定要文件扩展名，MVC框架支持URL“命名模式”，在SEO（search engine optimization ）和REST（representational state transfer ）定位中也工作得很好。举例，你可以映射“/products/edit/4”到你项目中的ProductsController类修改动作；或者映射“/Blogs/YourSite/10-10-2007/SomeTopic/”链接到BlogEngineController 类的DisplayPost 动作。URLs 无需与文件名称有关联。

4、在现有的ASP.NET页面（.aspx文件）、用户控件（.ascx文件）支持标记语言以及支持Master页面(.master文件)作为视图模板。你可以在使用ASP.NET MVC框架的同时使用现有的ASP.NET特性，如内嵌Master Page，嵌入表达式（<%=%>），声明式服务器控件，模板，数据绑定，本地化，等等。

5、支持现有的ASP.NET特性。ASP.NET MVC 可以使用特性如Forms和Windows的验证，URL验证，membership和roles，输出和数据缓存，Session和状态描述管理，监控健康状态，配置系统，provider的扩展架构，以及ASP.NET的其它领域。

后台

在ASP.NET网页，URL可以映射存在硬盘上的文件（如.aspx文件）。这些.aspx文件包括代码和标记，用于回应请求。

ASP.NET MVC框架用不同的方法映射链接到服务器代码。框架直接映射URL到控制器的类，代替映射URL到ASP.NET页面或使用handlers。控制器类处理引入的请求，如用户输入和用户交互，基于用户的输入以及执行相应的程式和数据逻辑。一般来说每一个控制器类调用一个视图组件，从而视图组件产生HTML输出。

ASP.NET MVC框架分离了Model，视图和控制器组件。模型组间一般使用在数据库的持久数据维护状态。控制器选择相应的视图组件，呈现适当的UI。大部分情况，ASP.NET MVC框架使用ASP.NET页面（.aspx）、用户控件（.ascx）、Master页面(.master)呈现页面到浏览器。控制器组件在控制器中定位适当的动作，使用动作方法的参数获得相应值，处理执行动作期间的所有异常，以及呈现所请求的视图。每一套的组件分别存在于MVC网页应用程式项目子目录。

URL映射

ASP.NET MVC框架包括一个URL映射的引擎，它提供了灵活的映射URL到控制器的类中。你可以使用映射引擎定义页面链接导航规则，ASP.NET MVC 框架会估计引进的URL和选择对应的控制器执行。你也可以让导航引擎自动添加变量定义到URL，ASP.NET MVC框架就会传递这些参数到控制器。

MVC 框架和Postbacks

ASP.NET MVC框架不会使用传统的ASP.NET postback模型来与服务器做交互。替代的是，所有的终端用户交互都由控制器控制。这样可分开维护UI逻辑和业务逻辑部分，有助于测试。这样导致的结果就是，ASP.NET 的视图状态、页面的生存周期事件都没有整个到基于MVC的视图当中。

创建ASP.NET MVC应用程式

ASP.NET MVC框架包括VS项目模板，让你创建支持MVC模式的网页应用程式。MVC Web Application 模板创建一个由子目录、模板、配置文件配置的网页应用程式，它们去全部都是ASP.NET MVC 程式所需要的部分。

默认情况下，当你使用模板创建新的网页应用程式的时候，Visual Studio 会创建一个解决方案和添加两个项目到解决方案。第一个项目就是实现你程式的网站项目，另外一个就是提供给你编写你的MVC组件单元测试的测试项目。

你可以使用任何兼容.NET框架的单元测试框架来测试ASP.NET MVC应用程式。Visual Studio 2008 Professional 包含了内置支持MSTest的测试项目。

了解MVC网页程式结构

当你创建ASP.NET MVC应用程式项目时，MVC组件基于以下的项目文件夹做分割：

1、视图文件夹。推荐视图文件夹内只存放视图。视图使用 .aspx, .ascx, 和 .master文件，当然其他任何文件也可以关联呈现视图。视图文件夹根据每一个控制器类的前缀而命名（如有Controller为“ProductsController”，View就有对应文件夹“Products”）。当加载视图时，默认地，ASP.NET MVC 框架会在Views\controllerName文件夹内寻找所请求的aspx文件视图名称。有一个叫“Common”的文件夹跟任何控制器没有关系。这个文件夹可用于定位存放master page、脚本、CSS文件以及呈现视图时要使用的其他文件。

2、控制器文件夹。推荐控制器文件夹内只存放控制器。

3、模型文件夹。推荐模型文件夹内只存放模型。一般来说，这里包含的代码就是定义与交互数据库的逻辑。

4、App_Data。数据的物理存储。这个文件夹与基于表单的ASP.NET网页应用程式作用相同。

在以上的文件夹之外，MVC还是用了以下的元素：

1、Global.asax 和 Global.asax.cs (在Visual Basic为 Global.asax.vb)。导航是在Application_Start 方法初始化的。以下示例展示Global.asax文件包含了默认的导航逻辑。

2、配置。MVC要在Web.Config注册HTTP handlers 和 HTTP modules。httpHandlers段注册MvcHandler类，用来导航请求到对应的控制器。以下示例显示httpHandlers段在ASP.NET MVC 的配置。

httpModules 段要注册UrlRoutingModule 类，强制URL导航到相应的处理者。这个入口允许程式在同一个项目是否使用MVC Handlers。以下示例显示httpModules段在ASP.NET MVC 的配置。

当你创建MVC程式的时候，方案已包含了测试项目。你可以使用MVC模板创建测试和创建mock来实现内置的接口。

了解MVC项目执行进程

使用MVC框架建立对网页的请求，通过 ASP.NET HTTP module 和 an HTTP handler进行导航。

注意
当MVC项目在IIS7运行的时候，无需注册任何文件后缀名。然而，在IIS6，处理器需要你映射.mvc文件后缀名到ASP.NET ISAPI DLL。

The module 和 handler 是指向 ASP.NET MVC框架的入口，会做以下动作：

1、在MVC项目中选择适当的控制器。
2、包含具体制定的控制器实例
3、呼叫控制器的方法

以下表格列出MVC项目执行场景：

Stage	Details
初次请求	在Gloabal.asax文件内，导向添加的RouteTable 对象。
导向	UrlRoutingModule 模块从在RouteTable实例中对应的Route 对象创建RouteData。 Route data 决定哪个控制器被请求，并且哪个方法被调用。
映射到控制器	MvcRouteHandler handler 根据RouteData实例中的数据，尝试创建控制器的类型。
调用控制器创建者	处理器调用ControllerBuilder 类的静态方法CreateController ，包含在IController 实例。 如果没有返回IController 实例，handler 会指定服务器返回HTTP500的错误。
创建控制器	ControllerBuilder 实例世界创建新的控制器实例，或者使用IControllerFactory 对象创建控制器。
执行控制器	MvcHandler 实例被添加到上下文，然后调用控制器的方法。

允许用户请求获得太多的数据，以至于消耗程式过多的资源，造成服务器不必要的紧张。这种不必要的压力导致增加CPU的使用率，增加内存使用量以及降低了反应次数。客户自然而然地，链接速度就会变慢。从可用性角度来说，大部分用户不会想在一个页面看到成千上万笔数据的呈现。。执行一个分页方案，从数据库中获取只想看到的一部分数据，减少后台数据库的工作量。你应该优化从数据库服务器到中间网站服务器获取数据的效率。要获取更多的信息，可以读这篇文章(http://weblogs.asp.net/scottgu/archive/2006/01/01/434314.aspx)，在数据库层面实现分页。如果你是使用SQL Server2000，也看看这篇文章（http://www.codeproject.com/aspnet/PagingLarge.asp）。

12. 显示关闭所有资源【Explicitly Dispose or Close all the resources】

当出现异常时，使用try/finally模块，保证资源被清除。在finally模块关闭资源。使用try/finally模块可以确保即使出现异常状况，资源也被关闭。在你需要打开连接的时候才打开它，并且在你完成任务后，尽快地关闭掉。你应该永远记住这句话：“进来，处理完数据，立刻走”。如果你使用了多个不同的对象，你要确认已经调用了各个对象所提供的Dispose 或Close。如果调用Close或Dispose失败的话，在客户端停止使用它们后，对象在内存还会延长它的生命周期。延迟清除资源会增加内存的压力。数据库连接和文件IO读写，就是应该显示关闭的例子。

13. 禁用跟踪和除错【Disable tracing and debugging】

在你发布配置你的应用程式时，应该禁用跟踪和除错。跟踪和除错功能会导致一些性能的问题。当你的程式在正式环境运行时，并不推荐开启跟踪和除错功能。你可以使用以下的语法，在Machine.config和Web.config文件中禁用它们。

14. 预编译页面，禁用自动匹配属性【Precompile pages and disable AutoEventWireup】

尽量使用预编译页面，不要让用户有机会访问批量即时编译的ASP.NET文件；因为这将会增加用户消耗的性能。

另外，在Machine.config设置AutoEventWireup属性为false，你的页面将不会根据一些匹配的方法名称而自动调用它们（如，Page_Load）。如果开发人员想使用这些事件，它们可以重写基类的方法（如，他们可以重写页面的Page.OnLoad，替换使用Page_Load的方法）。如果你禁用了AutoEventWireup，你使用事件绑定替代原来的自动呈现方法，页面性能会得到轻微的提升。

15. 使用存储过程和索引【Use stored procedures and indexes】

在大部分的情况下，使用已编译后的存储过程代替特别的查询会获取更多的性能改善。

确认你的表都正确地添加了索引。尝试使用“索引优化向导”（Index Tuning Wizard ），你可以获得他的一些关于最好的索引建议，可供选择。你无需遵守所有以下的建议，但它可能会提示出关于你的结构和数据的一些信息，这些都对你选择更适合索引有所帮助。

 1）在SQL Server Management Studio (SQL Server 2005), 选中你的Sql语句。在菜单选择“查询”=》“显示估计执行计划”，查看查询开销和索引使用详细信息（快捷键Ctrl +L）。
 2）在Sql2000也有类似的“索引调整向导”。在查询分析其中，选中你的Sql，选择在菜单选择“查询”=》“Index Tuning Wizard”。

引用

改善.NET程式的性能和可扩展性 (发布于 2006, February 12).

 1）禁用一个页面的Session状态，直接设置@ Page 的EnableSessionState 属性为false。如：
 <%@ Page EnableSessionState="false" %>
 2）如果你的页面只需要访问Session变量而不需要创建、修改它们，直接设置@ Page 的EnableSessionState 属性为ReadOnly。如：
 <%@ Page EnableSessionState="ReadOnly" %>  
 3）禁用服务器的所有程式使用Session，在Machine.config使用以下元素设置：
 <sessionState mode='Off'/>

6. 使用Server.Transfer【Use Server.Transfer】

在同一个应用程式中，使用Server.Transfer 方法重定向页面。

使用Server.Transfer这个语法，避免了不必要的客户端重定向。可以考虑使用Server.Transfer替代Response.Redirect。然而，你也不能总是使用Server.Transfer代替Response.Redirect 。如果你需要在重定向期间，做验证、授权处理，就必须使用Response.Redirect；因为这两种机制不相等。当你使用Response.Redirect，确认你使用了第二个参数为bool类型的重载版本，并传递false值，这样就可以确认内部的异常不会触发。同时，也要注意，你只能使用Server.Transfer 在同一个程式中，在页面定向间传递控件信息。如果要转页面到其他程式，必须使用Response.Redirect。

7.适当使用服务器控件，避免嵌套深层的控件。【Use server controls when appropriate and avoid creating deeply nested controls】

HTTP协议是无状态的；然而，服务器控件提供能强大的模型，使用了ViewState在管理页面间请求之间管理它的状态。没有免费的午餐，服务器控件需要一定数量的进程去建立自身控件和它的所有子控件。这一点，服务器控件对比HTML控件或静态的文本，相对地花费更多内存。当你不需要复杂的交互时，在用户界面使用一些内嵌服务器函数来替代服务器控件呈现界面。如果是以下条件，请替换服务器控件：

 1）你不需要在回传之间维护状态
 2）控件只负责静态输出数据，或者控件显示只读的数据
 3）不需要在服务器端编程访问控件

替换服务器控件方法可选择，简单rendering、HTML元素、用<%%>尖括弧内嵌调用 Response.Write。平衡你的选择是非常重要的。如果你的程式性能还可以接受，或者你对你程式的性能要求有限，那就避免过渡优化你的程式。

深层级嵌套的复合控件，需要花费一定的内存去建立自身控件和它的所有子控件。深层级结构导致创建额外的进程；这可使用html控件或使用更简单层次的服务器控件来避免。当你使用的控件如Repeater, DataList, 和 DataGrid 就要特别注意，因为他们将会在他们的容器中创建许多附加的子控件。

8.选择适合你的“检视”控件【Choose the data viewing control appropriate for your solution】

怎样选择如何在Web Form页面呈现数据，通常的重要依据是看便利和性能方面的权衡。在你选择使用控件之前，一定要对比一下他们的优劣之处。举例，你可以选择这三个控件(DataGrid, DataList 和 Repeater)去呈现数据，你的任务是找出哪个控件能提供给你最大的好处。DataGrid 可以用最快捷、最简单的方法去呈现数据，但通常来说它是最耗费性能的。在一些简单的案例中，用自动生成HTML可以完成列表工作，但用户定制需求和浏览器兼容（browser targeting？）所引发出来的额外工作很快就会抵消之前的快捷和便利。Repeater 控件是一个在便利和性能之间折中的服务器控件。它高效、可定制、可设计。

摘要

文章列出了一些能使你的ASP.NET应用程式最优化的一些技术。它提供了一些共同的问题，设计方针，以及一些编程技巧，让你可以建置最佳的和健壮的解决方案。

简介【Introduction】

ASP.NET比传统的ASP强大得多，然而了解怎么使用它的强大去建立一个高效的、可靠的、健壮的程式也是很重要的。在此篇章中，我尝试突出一些关键的技巧，让你能使用它去尽可能地优化你的ASP.NET页面。篇幅可能比较长，我只能强调最重要的一些点。

1. 先计划调查，再做开发【Plan and research before you develop】

研究和调查.NET怎么使用才能真的有利于你。.NET为各个层次的应用程式设计和开发提供能各种各样的方案。这需要你要非常了解你自身的状况，以及每个能达到你目的的开发环境的好与坏。Visual Studio是一个全面的开发包，为实现同一个业务逻辑可提供能许多选项。检查每一个选项，并且为你即将来临的任务选择最适合的方案是非常重要的。用分层的手法，逻辑上划分你的应用程式：表现层、业务层和数据层。这不仅能让你能创建可维护代码，并允许你分别监控和优化每一层的性能。同时，清晰的逻辑分层也为程式的伸缩性提供了更多的选择。尝试减少你在code-behind文件的代码量，可以改善程式的维护性和伸缩性。

2. 字符串的串联【String concatenation】

如果处理不当，字符串的链接真的会导致程式性能的下降。你可以用以下两个方式串联字符串。

第一，在使用字符串的时候，直接添加新的字符串到现有的字符串。然而，这样的做法是非常消耗性能的（特别是你在循环中使用这种串联字符串）。当你添加新的字符串到现有的字符串时，.NET框架会先同时复制已存在和新的数据到内存进行串连，然后删除已存在的字符串，最后在新的字符串读出数据。过分冗长的串联字符串操作会非常消耗时间。

第二，也是比较好的办法，使用StringBuilder串联字符串。以下两个例子做相同的实现。如果你考虑使用哪种字符串串联方式，请你自己亲自分别测试一下两段程式。也许你会对结果非常意外。

结果：
String  :151.5579296秒
StringBuilder :  0.0600864秒
/*********************************************/

这是ASP.NET在许多情况下能提供一种能极大地提高性能优于传统ASP的其中一种。

3. 避免信息回传提交服务器【Avoid round trips to the server】

你可以使用以下一些技巧去避免不必要的回传网站服务器：

1. 尽可能地实现Ajax的UI。这个想法可以避免真个页面的刷新，并且只更新页面需要更新的一部分。在Scott's article(http://weblogs.asp.net/scottgu/archive/2006/01/01/434314.aspx)给了很多怎样使用Ajax Atlas和<atlas:updatepanel> 控件的一些很好的建议。
2. 使用客户端脚本。客户端验证可以帮助减少一些需要处理用户的请求。在ASP.NET，你也可以使用客户端控件去验证用户的输入。
3. 使用Page.ISPostBack属性，确认你只需在页面第一次初始化加载时呈现出来的信息，不在客户回传事件中也会响应。
   
     If Not IsPostBack Then 
     LoadJScripts()
     End If
4. 在某些情况下，不必要处理回传事件。你可以使用client callbacks 去从服务器端获取数据，代替整个页面的回传。详细请看http://msdn2.microsoft.com/en-us/library/ms178208.aspx。

4. 当必要时才使用viewstate【Save viewstate only when necessary】

ViewState 主要被用于服务器控件在回传页面数据时能保持它自身的状态。这些信息会传到客户端，从一个hidden的变量读取回来。ViewState 不必要存在在不需要它的页面。随着ViewState数据的扩大，会影响垃圾回收的性能。你可以根据以下的一些提示。以便优化使用ViewState。

 1）当你不需要ViewState的情况
 在ASP.NET默认的状况下，ViewState的状态是开启的。你不需要ViewState的原因可能是你的页面只是用来输出数据而已，或者你已经明确用户的每次请求你都重新加载页面。以下情况下，你不需要使用ViewState。

 a.你的页面不需要回传（postback）。如果页面不会回传信息给自己，或者页面只是用于输出数据，又或者页面不需要处理回应数据，你就不需要ViewState。

 b.你不使用服务器事件。如果你的服务器控件不处理事件；服务器控件不是动态的或没有数据绑定属性值，或者他们在每次请求中都会在代码中进行重新设置属性值，你就不需要ViewState。

 c.你会在每次页面刷新重新设置控件。如果你忽略旧数据，你在每次页面刷新的时候会重新设置服务器控件。你就不需要ViewState。

 2）禁用ViewState
 有几个方法可以不同程度禁用ViewState。

 a.禁用在页面上单个控件的ViewState，把控件的EnableViewState属性设为false。

 b.禁用单个页面的ViewState，在@ Page 的EnableViewState 属性指定为false。如：
  <%@ Page EnableViewState="false" %> 

 c.在指定程式禁用ViewState，可以在相关程式的Web.config 文件中添加以下元素：
  <pages enableViewState="false" />

 d.对网站服务器的所有网站程序都禁用ViewState，在Machine.config 中，修改<pages>元素如下所示：
  <pages enableViewState="false" />

 3）确定你的ViewState大小。
 启用页面的tracing 功能，你可以监控每一个控件ViewState的大小。你可以根据这些信息，决定优化ViewState的大小；或者决定哪些控件的ViewState需要禁用。