@hahaha酱油男
呵呵，主要说一些很好玩的发现。我觉得你说的第二点其实是在反驳你的第一点，你的第一点是在揭穿你的第二点。
其一，第一点中你说我们以不同的网络环境作对比，这个可能是你误解了，我们比较的同样的网络状况下，WebForms的与postback相关的代码、请求数据等等都要比普通的post大上好多，这肯定是会影响传输效率以及整体的运行效率的。
其二，你第二点的比较使用了你第一点所反对的“不公正”的比较，拿出两种特殊而且极端的情况对两种架构进行比较。这好比在讨论“北极温度高还是赤道温度高”的时候，你非要说赤道的冷库很冷，北极的桑拿室很暖和，这样失去普遍意义的比较在技术层面是没有意义的，你说呢？
还有对于你说的“效率”问题我文中也说了，这不只是“运行时”效率，还包括开发、日后维护等等方面的效率（当然MVC在开发上的效率很多时候是要做一些牺牲的）。
另外，我不知道你睡了多久？这个讨论是在7个月前进行的:)
@菜无罪1
正式版还没有发布。从单纯页面开发上来说确实很asp，当然这个“没有控件”也只是针对V层的开发而言，MVC本身在这方面追求的就是这种高度的可控性，其他语言和结构方面的优势还是和WebForm没有太大区别的:)
mvc正式版发布没有，回到asp，没有控件的时代了。
一觉醒来，发现这么多人在争论mvc和webform
仅提2点
1有关效率，我同意以pos来比mvc和webform，但是注意对比的公正性，不能拿 正常 的网络状况下的mvc（比如0.1秒），来比网络 拥堵 时的webform的低效率（比如5秒）。在同样网络拥堵时，mvc的url，同样也会很慢的，这时http的问题，不是前端的问题。
http服务的响应效率就是比c/s的低，mvc在一些情况下会好点，但不会有质的飞跃。
其实软件哲学可以解释这些，模式仅仅为了结构合理，而不是效率提升，而往往结构合理的代价是降低效率，如C到C++，本地代码到中间码
2有关耦合。webform怎么就是紧呕了呢，任何粒度的划分都是相对的，更多的分层或解耦可以在后面作多少层都可以的，也可以mvc，仅把webform作为表现。表现层如果再细分，子子孙孙无穷尽也。
MVC怎么就松呕了呢？如果你放在一个包里（dll或project），那你的松呕就没有意义嘛！松偶的目的不是简单分开就完事了的。
由于争论太多，我醒的太晚，时间太短，还得去买酱油，大略看了一下，主要针对楼主的比较方式提出质疑，科学是需要方法论的。
继承自ITemplete的“模板”我觉得在MVC里面似乎不太用的到啊，本身就不提倡使用runat=server的控件，那么所谓“模板”能直接输出HTML代码就已经OK了阿
那里面的itemTempletes已经可以达到这些基本要求了哇
我不知道你说的是像WebFrom服务器控件那样继承自ITemplete那样的“模板”，还是repeat循环体内的的输出？
（汗，明明是跟贴的，怎么编辑掉了？bug?）
@SZW
模板功能就是要像普通的Repeater一样，有ItemTemplate啊
Repeater更应用有模板，没有模板Repeater发挥不出它的功效。
Repeater在这里作为一个“轻量级”的方法出现，在下面GridView中你会看到模板:)
@Elden
试了一下，好像还是没有用哦。
@郭荣维
欢迎交流:)
哎，从1到3，我都用过。。p3好好了好多。。目前也用在项目中。。正在用中。。刚觉，挺好的。。建议楼主建个qq群，把我们都加进去吧。。。
如果建了。记得加我qq啊。。759922422
@SZW
RedirectToAction确实也存在这样的问题。
你可以试试用代理访问
@王孟军！
:)
@Elden
怎么打不开呢？
似乎这个问题除了上面几个方法里面，RedirectToAction也存在着同样的问题。
速度很快
不过，我 一直没 用 ASPNET MVC
补充了一些内容：
还有一点点期望：
1、Html.DropDownList(原Html.Select)在数据源的类型上可以更丰富一些，特别是直接接受IDictionary类型的数据源（目前由于IDictionary htmlAttributes的重写方法，这个类型会被认为是一个属性的集合）。
2、Preview3里面一改以往必须在RenderView中输入.aspx/.ascx文件名的要求，可以根据Action名称直接View();并且每个Action都要返回一个ResultAction类型，这时候，我们可以通过return RedirectToAction(actionName)来执行另外一个Action（RedirectToAction 返回的也是ResultAction类型），但是我又想到一个更加方便的方法（不知官方这么用了没有）——直接return actionName()——这个方法除了输入方便，还助于在编译时检测actionName的正确性，以及传参的正确性及便捷性。因为返回类型都是ResultAction。我尝试了之后，发现是可行的，但是有一个跟View()方法有关的问题出现了：比如我在Action1中，return Action2();而在Action2中，我只是View()，没有View("Action2")，这时候由于方法名称还是Action1，所以在运行到Action2的View()的时候，会自动查找Action1.aspx/ascx，而非Action2的。这里有点遗憾，如果View()方法是可以再丰富一下，查找其直接所属的方法的名称，那这个功能就更加完美了。
@SZW
*^0^*呵呵，不好意思冤枉楼主料～
不过大家吵了哪么久，还是看看官方有没有什么反应吧，呵呵
感觉url.action确实是有点问题，呵呵
--引用--------------------------------------------------
没剑: 偶查看了一下源码，发现url.action里调用的方法为：
...
所以楼主的：
很显然,这儿如果routeName为null的话系统会优先根据routename查找
－－－
我继续看了下源码，但好像未发现routeName为null时系统会查找routeName。。。
--------------------------------------------------------
冤枉哈~“很显然,这儿如果routeName为null的话系统会优先根据routename查找 ”这句话不是我说的，正是我要纠正的。见24楼
@没剑
RouteUrl提供了RouteName的查找方式，他的关键字段只有一个单独的key,比action+controller更加直接和有效，但是在Url.Action和Html.ActionLink（这个没办法用RouteUrl替换了，除非我们直接静态输出<a>标签）中提供的只有actionName，不管怎么样在这里忽略了判断controller，应该是个疏忽，或者是Url.Action重写方法上的一些问题。
@小No
好像csdn已经引用了我这篇文章并且反映过去了，我自己也留言了，等待官方的答复。
不过我倒是觉得：Url.RouteUrl这个方法的功能比较符合楼主的意思，这个才是正儿八经的按RouteName查找
相关的源码如下，你们大家找找看：系统有没有在routeName为null时会自动查找routeName
------------------没剑的丑陋的分隔线-----------------------------
internal static string GenerateUrl(string routeName, string actionName, string controllerName, RouteValueDictionary valuesDictionary, RouteCollection routeCollection, ViewContext viewContext)
{
VirtualPathData virtualPath;
if (actionName != null)
{
if (valuesDictionary.ContainsKey("action"))
{
throw new ArgumentException(string.Format(CultureInfo.CurrentUICulture, MvcResources.Helper_DictionaryAlreadyContainsKey, new object[] { "action" }), "actionName");
}
valuesDictionary.Add("action", actionName);
}
if (controllerName != null)
{
if (valuesDictionary.ContainsKey("controller"))
{
throw new ArgumentException(string.Format(CultureInfo.CurrentUICulture, MvcResources.Helper_DictionaryAlreadyContainsKey, new object[] { "controller" }), "controllerName");
}
valuesDictionary.Add("controller", controllerName);
}
if (routeName != null)
{
virtualPath = routeCollection.GetVirtualPath(viewContext, routeName, valuesDictionary);
}
else
{
virtualPath = routeCollection.GetVirtualPath(viewContext, valuesDictionary);
}
if (virtualPath != null)
{
return virtualPath.VirtualPath;
}
return null;
}
偶查看了一下源码，发现url.action里调用的方法为：
public string Action(string actionName)
{
if (string.IsNullOrEmpty(actionName))
{
throw new ArgumentException(MvcResources.Common_NullOrEmpty, "actionName");
}
return this.GenerateUrl(null, actionName, null, new RouteValueDictionary());
}
这里GenerateUrl的第一个参数为routeName，而调用url.action(ActionName)时，routeName为null
所以楼主的：
很显然,这儿如果routeName为null的话系统会优先根据routename查找
－－－
我继续看了下源码，但好像未发现routeName为null时系统会查找routeName。。。
这看来真的是个BUG，当我把规则改成：
routes.MapRoute(
"Home_About", // Route name
"Home/About/aaa", // URL with parameters
new { controller = "Home", action = "About" } // Parameter defaults
);
<%=Url.Action("About")%> 返回的是Home/About/aaa，看来他连默认的Action都找了，谁英文好，去提一下这个BUG
@Leven
----引用--------------------------------------------------
很显然,这儿如果routeName为null的话系统会优先根据routename查找
----------------------------------------------------------
这句话是不是应该：
很显然,这儿如果routeName不为null的话系统会优先根据routename查找
？
@没剑
--引用--------------------------------------------------
没剑: @SZW
我又试着把Defaut这个MapRoute删除，只保留一个About这个MapRoute，然后访问其它页出错，完全找不到路径，只有home/About这个页能够找到
从这里可以看出Default这个名称的MapRoute规则是一个特殊的规则，它起到了一个全局性的全用。。。在使用的时候一定要将它放在第一个位置执行，不然可能会对Route设置出现一些意想不到的错误
--------------------------------------------------------
Default那一个是不能删除的，而且应该放在最后。另外关于routeName就像Leven说的那样。
@Leven
是的，官方有说可以用routeName。但是在Url.Action里面找不到单一传入routeName的方法，只有actionName，所以这种情况下为了持久的可用性（以应对routing规则的随时变化），默认的Url.Action(actionName)的方法就不能使用了。
...不小心把评论弄掉了,重新写了个记录研究过程的:
http://www.cnblogs.com/leven/archive/2008/05/30/1210606.html
@没剑
--引用--------------------------------------------------
没剑: @SZW
楼主，我发现问题所在了，你的哪句MapRoute是放在RegisterRoutes最前面的，而默认哪一个：
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = "" } // Parameter defaults
);
这个则放在了后面，我试着调换了一下位置，出来的结果就是正确的了，
我不知道这个路由起的作用是什么，我只知道是用来转换/...--->/home/index
这个路径，这样子看起来它的作用好像是一个全局性的。。。
希望知道的朋友可以告知一下～
--------------------------------------------------------
嘿嘿，你这个不是解决问题，是把问题隐藏了而已——Default是全局默认配置，只有当所有的都不符合的时候，才执行Default，你把Default放到第一个，就会发现下面的都失效了。你可以做这么一个实验：
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = "" } // Parameter defaults
);
routes.MapRoute(
"Home-About", // Route name
"Home/About/{msg}", // URL with parameters
new { controller = "Home", action = "About",msg="" } // Parameter defaults
);
然后在任意位置输出<%=Url.Action("About","Home", new { msg = "123" })%>，理想状况应该是：Home/About/123对吧？这时候肯定是：Home/About/?msg=123
所以Default放在第一个是不行的哦:)
再看看还有没有别的地方存在问题。
@SZW
我又试着把Defaut这个MapRoute删除，只保留一个About这个MapRoute，然后访问其它页出错，完全找不到路径，只有home/About这个页能够找到
从这里可以看出Default这个名称的MapRoute规则是一个特殊的规则，它起到了一个全局性的全用。。。在使用的时候一定要将它放在第一个位置执行，不然可能会对Route设置出现一些意想不到的错误
@小No
是的，官方是这么说的，但是你可以自己实践一下，即使改成了别的比如"Home-About"，问题仍然存在，你可以看这个Demo：
http://www.cnblogs.com/Files/szw/ASP.NET_MVC_Preview_3_-Routing_bug-1.rar，把Global里面的"About"改成别的，结果还是一样的。你说的routeName的方法不在Url.Action里面，而是Url.RouteUrl，所以使用Url.Action的时候还是存在这样的问题哦。
@SZW
楼主，我发现问题所在了，你的哪句MapRoute是放在RegisterRoutes最前面的，而默认哪一个：
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = "" } // Parameter defaults
);
这个则放在了后面，我试着调换了一下位置，出来的结果就是正确的了，
我不知道这个路由起的作用是什么，我只知道是用来转换/...--->/home/index
这个路径，这样子看起来它的作用好像是一个全局性的。。。
希望知道的朋友可以告知一下～
@SZW
这个是Preview3 新的Routing规则，不是bug
Preview2的时候，MapRoute的Name是没有用的，
在Preview3里变得有用了，例如：<%=Url.Action("About")%>
它会首先在规则里找有没有一个name为about的规则，有的话就自动生成适合规则的Url，也就是/Home/Login。否则才去匹配其他的规则。
所以为了避免出现这种情况，MapRoute的name最好起一个不要跟Action会重复的名字，例如Home_About，就不会出现这种情况了。
@没剑
效果应该是一样的，我的不是
routes.MapRoute( _
"Login", _
"Admin/Login", _
New With {.controller = "Admin", .action = "Login"} _
)
是在Home里面：
routes.MapRoute( _
"Login", _
"Home/Login", _
New With {.controller = "Home", .action = "Login"} _
)
你试试看。
我用C#比如是这样的：
routes.MapRoute("News-News",
"News.xhtml/News/{NewsGuid}",
new { controller = "News", action = "News", NewsGuid = new Guid() });
然后你在Admin里面输出：Url.Action("News")
@SZW
楼主，我刚刚试了一下你说的第一个bug，routing这个
我测试过没有问题哦，你具体是怎么样产生的错误？
我在Golbal里添加的route规则是：
routes.MapRoute( _
"Login", _
"Admin/Login", _
New With {.controller = "Admin", .action = "Login"} _
)
偶是:admin/admin home/index下分别使用：<%=Url.Action("Login")%>
来产生链接，结果是：
admin/admin：/admin/Login
home/index：/Home/Login
没有你说的哪种错误哦～
@Leven
恩，对的，我测试的时候用了Preview3的Default.aspx，已经用了<%@ Page Language="C#" %>，所以发现这样改会有问题，已经修正，谢谢提醒！
dit the Default.aspx file and add the following line:
<% Response.Redirect("~/Home") %>
官方这儿语法是正确的,因为默认的aspx解析不是c#,而是VB.Net,因此你如果加分号反而有问题.
还有一些路由的BUG好像，在早期版本（包括0416版本）中都可以正常的路由规则在P3中却不能用了。
@SZW
我记得我在Preview2里情况跟现在是一样的。不过放的时间长了，记不得是不是了。也可能是我记错。
@第一控制.NET
我在Preview2里面用Url.Action("Foo") 是正常的，哪怕Global里面注册一条规则也能返回正常的URL。以前你碰到的情况是怎么样的？
Url.Action("Foo")
这个问题是一直存在的。啥原因谁清楚。。。
@Q.Lee.lulu
这些判断肯定跟Routing的顺序有关系的，要是建一条Admin.Foo的在Home.Foo的前面，就不会找到Home里面去了，但是可惜他判断的时候找到一个相同的Action就算配上了，忽略了当前的controller。UrlAction之类的方法应该没有怎么变动，估计是这次修改的System.Web.Routing.dll里面的问题了。