base.ViewLocationFormats = new string[] { BaseviewPath + "/{1}/{0}.aspx",
BaseviewPath + "/{1}/{0}.aspx",

以及下面Shared里面的，是不是第二个应该为.ascx？

@云の世界
可以考虑更进一步，使用Views_Red,Views_Blue，这样更加独立，而且不需要受模板限制，兼容原始状态。

@阿不
--引用--------------------------------------------------
阿不: @SZW<br>我觉得可以这样：<br> 把RouteTable做到可配置的，不要在程序中写死，做成一个可配置文件。然后在配置文件中，配置所有的Controller,Action和参数，还有访问权限等。
--------------------------------------------------------
是个不错的方法！

我只是按了F5，没有刷新两次阿，而且是在设断点的情况下，Attribute中的代码连续运行了两次

不错，看看去

把Form和QueryString区分开来主要用意是什么呢？

我大概想的和Q.Lee.lulu有点接近，哪怕web.config中可以设置，在一些时候也很笨拙。其中一个原因是MVC的Controller即使路径上面“外貌相仿”，但是实际出现的个数可能要远远大于WebForm中的文件夹个数，而且表面上看来是比较零乱的，这里面维护起来压力很大（当然我们也可以按照Home,User,Admin这样的分类，不过很多时候我们还是会按照Products,Customers——貌似也是DynamicData应用的趋势，这里面的Action权限可能是细分的，在Web.config里面也能做到，但做起来就比较累人了），除此之外，这样基本上限定了Controller必须在Url第一节的用法，似乎有点太“过分”了。当然这种情况是可以人为控制的。全部在Controller里面控制我也不觉得是最好的选择，倘若能够在Web.config里面针对Controller和Action的一些规律进行判断的话就更好了。

@阿不
新打开一个页面不会，你保持Attribute中的断点，刷新一下看看。
我也是偶然的一次调试中发现这个问题的，今天发现新打开的不会这样，也算松了半口气，哈哈。

@BlackCat
期待:)

挺全面，不过好像对标题说的内容讲的不够透彻。Mass SQL Injection 还是在输入的时候就Encode效率更加高一点，但是一般的EnCode好像单引号是不会处理的，所以最好自己再扩展一下，把单引号也Encode了就更加安全了。

支持:)

@BlackCat
多多交流:)

呵呵貌似我一开始眼拙了，没看到你写的第三点:P其实我说的也可以算在性质效用里面。基本上这三个效用可以涵盖大部分情况了。第三点和前两点不同的只是形质效用是现代物流催生出来的，并不是物流原始的动机。我从上学的时候就觉得把第三点和前两点并列起来讨论似乎太别扭了，它是更加高一层次的增补性质的劳作，也就像我说的是时间、空间效应以及很多技术的集合。

哈哈物流的要顶！

还有一个空间和时间结合的效应：物流环节的流通加工，同时降低了仓储、加工场地等等的成本。
比如我们路上经常看到的混凝土车辆，发现他们后面的斗是一直在转的，这么做一方面是为了防止凝固，另一方面是利用运输的时间，在到达目的地的时候正好把混凝土搅拌均匀，可以直接投入使用。

@阿不
我之前也试过在Controller上面直接加一个OnActionExecuting，使下面的Action不用每个都标记属性，但是发现有一个问题，程序在进入Controller和Action的时候，会对这个验证分别运行一次（虽然从程序运行逻辑上来说合情合理），也就说在使用了这个验证（比如RequiresRoleAttribute）的时候，一个请求要读两次数据库（暂不考虑缓存），这个问题有办法解决吗？

@hahaha酱油男
呵呵，主要说一些很好玩的发现。我觉得你说的第二点其实是在反驳你的第一点，你的第一点是在揭穿你的第二点。

其一，第一点中你说我们以不同的网络环境作对比，这个可能是你误解了，我们比较的同样的网络状况下，WebForms的与postback相关的代码、请求数据等等都要比普通的post大上好多，这肯定是会影响传输效率以及整体的运行效率的。

其二，你第二点的比较使用了你第一点所反对的“不公正”的比较，拿出两种特殊而且极端的情况对两种架构进行比较。这好比在讨论“北极温度高还是赤道温度高”的时候，你非要说赤道的冷库很冷，北极的桑拿室很暖和，这样失去普遍意义的比较在技术层面是没有意义的，你说呢？

还有对于你说的“效率”问题我文中也说了，这不只是“运行时”效率，还包括开发、日后维护等等方面的效率（当然MVC在开发上的效率很多时候是要做一些牺牲的）。

另外，我不知道你睡了多久？这个讨论是在7个月前进行的:)

@菜无罪1
正式版还没有发布。从单纯页面开发上来说确实很asp，当然这个“没有控件”也只是针对V层的开发而言，MVC本身在这方面追求的就是这种高度的可控性，其他语言和结构方面的优势还是和WebForm没有太大区别的:)

继承自ITemplete的“模板”我觉得在MVC里面似乎不太用的到啊，本身就不提倡使用runat=server的控件，那么所谓“模板”能直接输出HTML代码就已经OK了阿

那里面的itemTempletes已经可以达到这些基本要求了哇

我不知道你说的是像WebFrom服务器控件那样继承自ITemplete那样的“模板”，还是repeat循环体内的的输出？
（汗，明明是跟贴的，怎么编辑掉了？bug?）

@Q.Lee.lulu
嘿嘿:)

@阿不
哈哈是的，期待！

@阿不
是的，在MVC里面“（相对的）物理路径”已经被Controller/Action取代，所以当你把Controller/Action看作是不同物理路径下面的文件时，这种有点“变态”的权限控制还是生效的，而且工作的很好。当然前面我也说了，这样对MVC是有些脱节的。

你说的模板是具有哪些功能的模板？

Repeater在这里作为一个“轻量级”的方法出现，在下面GridView中你会看到模板:)

@阿不
其实目前的“基于角色的页面权限控制”在ASP.NET MVC说用也是能用的，区别就是把文件夹改成Controller或者url配置上的第一节（比如home或者home.xhtml），被过滤掉的Controller中的action也是不会被触发的，而且也能被弹回到loginUrl。只是这样做有时候不免有点和M-V-C的结构有点脱节，再有就是对复杂一点的情况控制起来十分吃力，还是要Controller中去判断。

Web配置系统：ASP.NET MVC仍然使用原有的配置系统，在Web.config中只是部分的配置节点不适用于ASP.NET MVC，比如页面访问授权配置。
======================
目前官方有没有提供类似的功能呢？
目前我能做的就是在Controller进入的时候判断一下权限，这样就失去了“配置”的优点。

@Elden
试了一下，好像还是没有用哦。

@郭荣维
欢迎交流:)

其实那个ID还是有规律的，就是"ClientID_<此Item的Index>"
比如ClientID是ctl00_RadioButtonList1，那么实际第一项的ID是ctl00_RadioButtonList1_0，第二项是ctl00_RadioButtonList1_1……以此类推

好象浮点数的判断有点问题，只要第一个字符是数字，后面接字母也会通过

支持一下:)
貌似有没有条码在这段代码里面也不是最重要啊，呵呵

@王孟军！
:)
@Elden
怎么打不开呢？

似乎这个问题除了上面几个方法里面，RedirectToAction也存在着同样的问题。

楼主也是学物流的？

--引用--------------------------------------------------
Leven: @SZW
这也不能完全这么说
如果是
&quot;{controller}/{action}/{msg}&quot;
和
&quot;{controller}/{action}/{id}&quot;
这也没辙,反正它只会认第一个.所以怎么放就只能根据你业务的原则了
--------------------------------------------------------
这样的用法其实不是“一般”和“特殊”的关系，他们是并列的，所谓“特殊”一般都是controller和action指定的（比如这里的msg这一条），而“一般”的都是“模糊”的，这时候当你不提供、不符合msg相关参数的时候，它就会认第二个，此时第一个是“特殊”的，第二个是“一般”的。现在确定了顺序之后，回过头来，看一下Url.Action，里面其实并没有提供RouteName的参数，只有ActionName/ControllerName及相关的，所以在Url.Action里面，应该是不会涉及到RouteName，那么问题就很简单了，如果在一个已知的ControllerName里面，Url.Action("Foo")返回了一个别的Controller里面的方法，你觉得算不算bug呢（如果不知道这个方法的真实意图，可以参考Preview2中的方法，那里面是正确的）？而RouteName相关方法，在Perview3中交给了Url.RouteUrl去处理，如果没有什么问题的话，这两个方法是井水不犯河水的。

@Leven
所以说先"Home/About/{msg}，后"{controller}/{action}/{id}"的“特殊”=>“一般”的方法很符合程序的逻辑和实际需要嘛。

不小心修改掉了，见14楼，呵呵

@Q.Lee.lulu
呵呵，闲话闲话:)

public ActionResult Confirm()
{
return RenderView(); //译注：参数为空时将呈现和action同名的view
}

=================
Pre3里面已经没有RenderView()了，是View()吧？

@Leven
不小心怎么我也弄成“修改”了，汗~

其实现在我们争论的问题最基本的是，我认为应该先“特殊”，也就是特殊的、个别的URL规则，然后“一般”，也就是更加通用的URL规则。而你的想法相反。这个如果不统一，可能我说的你也更加没法体会了。偷懒一点的话其实也不用去从源代码上面看，看看官方的是用户顺序，然后自己换一下，就已经很明了一些了。你说我那两个Action不同（http://www.cnblogs.com/szw/archive/2008/05/29/1209915.html 的20楼），其实并不是不同，而是一个已经涵盖了另外一个：
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = "" }
他的Action并不是Index，Index只是不提供时候的默认值。

@Leven
我在http://www.cnblogs.com/szw/archive/2008/05/29/1209915.html 谈到的应该是个bug，你文中的测试好像并没有针对深入到这个问题的实质，只是上比较了这两种方式，Url.Action其实跟routeName没有直接的关系，因为Url.Action("Foo")并不提供对routeName索引的支持，而且你也看到了，即使在global里面修改了routeName，情况一点都没有改变。

其一、Url.Action("Foo")在这种情况下失去了意义，甚至如果不点破不处理的话会使网页在不确定的时间产生不确定的错误，此时这种方法的存在本身就是一个bug。
其二、如果这种方法是有必要存在的（答案因该是肯定的），那么就是Routing内部配对URL规则上的错误，在查找actionName的时候，忽略了同时判断controllerName这个重要的参数，导致Url.Action("Foo")形同虚设甚至会给程序带来意想不到的错误，我想这不是官方的本意吧？所以在这种方法有必要存在的情况下，返回错误的结果当然是个bug。

补充了一些内容：
还有一点点期望：
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()方法是可以再丰富一下，查找其直接所属的方法的名称，那这个功能就更加完美了。

简言之，默认的Action方法是按actionName+controllerName查找，RouteUrl按routeName查找。他们查找的“关键字”是不一样的，在Url.Action(包括Html.ActionLink等使用actionName+controllerName方式的)里面，Preview3的这些方法查找到actionName就算完成了，忽略了一个重要的前提——controllerName。

--引用--------------------------------------------------
没剑: 偶查看了一下源码，发现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已经引用了我这篇文章并且反映过去了，我自己也留言了，等待官方的答复。

@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)的方法就不能使用了。

@没剑
--引用--------------------------------------------------
没剑: @SZW
楼主，我发现问题所在了，你的哪句MapRoute是放在RegisterRoutes最前面的，而默认哪一个：
routes.MapRoute(
&quot;Default&quot;, // Route name
&quot;{controller}/{action}/{id}&quot;, // URL with parameters
new { controller = &quot;Home&quot;, action = &quot;Index&quot;, id = &quot;&quot; } // Parameter defaults
);
这个则放在了后面，我试着调换了一下位置，出来的结果就是正确的了，
我不知道这个路由起的作用是什么，我只知道是用来转换/...---&gt;/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放在第一个是不行的哦:)

再看看还有没有别的地方存在问题。

@小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的时候还是存在这样的问题哦。

这次ResultAction真是一个很大的进步，返回一个ResultAction类型的思路，对于MVC中Ajax的实现也有很大的意义，不知道以后能不能再来一个ResultActionCollection，嘿嘿~

支持！已经用上了，感觉很好！谢谢博主！