[转贴一]
使用ASP.NET MVC框架，创建默认项目，第一直观感觉就是地址都是Rewrite过的。对源码和配置文件稍加分析不难看出，MVC使用了httpModules来拦截地址请求，具体用到了System.Web.Routing类库（MVC2中，MVC1怎么用的忘记了。）而这部分类库被包装在.NET Framework3.5 SP1中，MVC2需要SP1支持也就理所当然了。SP1提供的System.Web.Routing类库可以方便地进行地址请求拦截，对编码处理方面也很优秀。UrlRoutingModule类拦截请求，在这之前，Application_Start的时候，会给RouteTable的全局对象一个拦截的设置。而这个设置使用RouteCollection对象进行保存，MVC对这个类进行了扩展——RouteCollectionExtensions。这些可以不考虑，接下来，当用户访问页面时，UrlRoutingModule类拦截请求，在RouteTable中查看是否符合规则，符合的话，就会调用MvcHandler，这个调用在httpHandlers配置节点被注册，条件是地址符合“*.mvc”规则。MvcHandler的ProcessRequest方法就会调用Controller来执行。事实上整个过程都是黑盒子，用户感觉不到。在Controller中某方法执行后，返回结果，再进入具体的aspx页面。
分析了MVC的工作工程，就可以对比其与WebForm的区别了。我们知道，MVC模式的业务被放置到Controller中去执行，而aspx页面只负责显示。那么在MVC中的业务实际执行时间被提前到了HttpMolde中，而WebForm的请求只在httpHandler容器中被执行。也就是说MVC中Controller与View的分离是使用的ASP.Net请求管道隔离的，这样的话无疑在不影响效率（一次请求，而Response.Redirect是二次请求）的情况下达成了代码的逻辑层次的分离。
图1 MVC工作模型
MVC工作的优点是显然的，更加有利于理解分层逻辑，把握代码的层次感。Controller到aspx页面之间的过程，已经被框架隔离。至于Controller或者View页面与Model调用的过程，还是需要自己来把握。ASP.NET的MVC框架实现了Controller代码的单独管理。
而看WebForm开发模型，则只在HttpHandler容器中执行，对其进行分层，在大的方面缺乏支持，而只能依靠逻辑上分离。并不是不能分离，而是由一定的局限性。HttpHandler的拦截，是跟访问后缀名有关的。当请求一个页面时，那就是一个Handler，而WebForm模型实现显示与逻辑分离，才有的是WinForm的事件驱动。显然，事件必须被注册到页面里，比如Button1_Click这样的代码。而在Button1_Click执行之前，Page_Load方法会被执行。
显示代码被写入Page_Loa
方法一：<asp:LinkButton runat="server" ID="lbtnClick" PostBackUrl='<%#"~/test.aspx?id="+Eval("id")%>'>zhang</asp:LinkButton>
方法二：<asp:LinkButton runat="server" ID="lbtnClick" PostBackUrl='<%#Eval("id","~/test.aspx?id={0}")%>'>zhang</asp"LinkButton> ......
首先建立控件GridView1，注意噢
页面EnableEventValidation="false"必须的。
<form id="form1" runat="server">
<div>
<asp:GridView ID="GridView1" AutoGenerateColumns="false" runat="server">
<Columns>
<asp:TemplateField>
<ItemTemplate>
<asp:Panel ID="P ......
