ASP.NET MVC Beta Released

【原文地址】ASP.NET MVC Beta Released
【原文发表日期】 Thursday, October 16, 2008 3:30 PM

今天，我们发布了新的ASP.NET MVC框架的beta版，点击这里下载。你还可以访问 www.asp.net/mvc， 浏览一下教程, 快速上手, 和录像等以了解技术细节。
<script type="text/javascript"><!--google_ad_client = "pub-3555979289815451";google_ad_slot = "0437120238";google_ad_width = 468;google_ad_height = 60;//--></script><script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"></script>

ASP.NET MVC Beta版可用于.NET 3.5和.NET 3.5 SP1下，同时支持VS 2008 和 Visual Web Developer 2008 Express SP1版本（该版本是免费的，现在还支持类库和web应用项目类型）。

今天的ASP.NET MVCBeta版本带有一个明确的“上线（go-live）”许可，允许你将其部署于生产环境中。以前的预览版本也允许上线部署，但其做法只是没有拒绝部署的许可，而不是明确地允准许可（此乃很容易混淆之处），今天的版本在这一点上在许可中说得很清楚。

该beta版本的特性已经非常接近于正式版V1的完整特性，虽然还会在最终的V1版发布之前加入若干个特性（包括几个VS工具增强等）。但开发团队决定将这个版本称为“beta”版本，是因为其品质和测试要比以前的预览版本高(其中包含了许多缺陷修补和性能调校方面的工作),他们感觉，其中的核心功能现在已经“烧制”得足够好，从这个版本到最终版不会有重大变动了。

这个贴子包括了对该版本中一些新的特性和与早先的“第五个预览版”之间的变动的简短概述：

• Visual Studio中新的“添加视图”菜单项
• 新的 /Scripts目录和jQuery支持
• 对复杂类型的内置模型绑定器支持
• 重构的模型绑定器设施
• 强类型的UpdateModel和TryUpdateModel白名单过滤
• 改进的UpdateModel和TryUpdateModel场景的单元测试
• 强类型的[AcceptVerbs]特性
• 更好的验证错误信息
• HTML辅助方法的清理和重构
• Silverlight / ASP.NET MVC 项目集成
• ASP.NET MVC Futures 程序集
• /Bin 和 GAC 程序集部署

我还计划在将来的几个星期内发表几个全程（end-to-end）教程，给尚未研究过ASP.NET MVC的人，以及想从头学起，想知道如何起步的人更深入地解释ASP.NET MVC的概念。

Visual Studio中新的“添加视图”菜单项

在以前的ASP.NET MVC预览版中，你需要通过VS中的项目->添加新项对话框手工地添加视图，创建好一切，然后将它们连接起来要求若干个手工步骤（确认目录/文件结构是对的，进入后台文件指定强类型的ViewData模型类型等等）。

今天的beta版本简化了这些步骤，你现在只要在源码编辑器中将光标移进一个Controlleraction方法之内，然后右击，选择新的“添加视图（Add View）”上下文菜单项（或者你也可以键入Ctrl-MCtrl-V快捷键组合来启动，手不必离开键盘）：

这会调出一个新的“添加视图”对话框，允许你指定你想要创建的视图名称，其母版页，以及可选地，它的强类型ViewData“模型”类型：

 

VisualStudio会根据你的光标所在的action方法自动地填充视图名称（然后你想要的话，也可以改动）。例如，如果在选择“添加视图”时，我们的光标是在“Edit” action方法中的话，它会在视图名称对话框中填“Edit"，而不是“Browse”。

视图的强类型ViewData“模型”可从可编辑的ComboBox中选择，该ComboBox列出了MVC项目中所有的类（或者引用的类）：

然后，你可以从列表中选一类型，或在ComboBox中手工输入一个类型。或者你也可以先从列表中挑一初始类型，然后做些改动。例如，我们可以从列表中选择“Product”类，然后使用ComboBox的编辑支持，将其改成IEnumerable<Product>，意即一个产品序列：

在点击“添加”按钮后，VisualStudio会自动地生成合适的视图目录结构，往我们的项目中加一个适当名称和基类的强类型视图。例如，我按上面的步骤做的话，它会为我生成一个新的/Views/Products目录（因为我的控制器类名是ProductsController），在其中加一个强类型的Browse.aspx视图（该视图从ViewPage<IEnumerable<Product>>继承而来，因为这是我们在上面对话框中指定的模型类型）：

新生成的视图会在IDE中自动打开，然后我们可以使用完整的intellisense实现视图（小技巧：确认在创建视图后立刻编译一下，以确保你的强类型模型会在intellisense中出现）：

在运行时，我们就能得到一个用ASP.NET MVC建造的SEO优化的产品浏览网页：

注：在这个beta版本中通过“添加视图”生成的视图文件是空白的，在最终版中，我们希望在“添加视图”对话框中加一些“scaffolding（脚手架）”功能，允许你指定你想要根据“添加视图”对话框中指定的强类型模型来自动生成HTML列表/细节视图或者编辑/插入表单（然后你可以从这起始的html视图开始，改成你想要的东西）。在将来，我们还将把ASP.NET动态数据与MVC集成，来支持更丰富的“scaffolding”选项。

新的 /Scripts目录和jQuery支持

今天的版本中发布的项目模板会在项目的根目录下加一个 /Scripts 目录，这是现在应用中推荐存放JavaScript文件的地方。

ASP.NET MVC Beta版本现在会将ASP.NET AJAX和jQuery库同时加到这个文件夹中：

其中的jQuery文件是标准的jQuery库，是在MIT源码许可下发布的（阅读我先前的《jQuery和微软》一贴了解有关详情）。

在VS2008或者 Visual Web Developer 2008Express版本的SP1版中，在使用上面的jQuery文件时，你会得到基本的JavaScriptintellisense。几个星期后，我们将发布一个 jQuery intellisense注释文件，将提供更棒，更完整的jQueryintellisense支持（包括在使用多个串连选择器/命令时得到intellisense的能力）。这将内置包含在下一个ASP.NET MVC更新版本中。

表单提交和模型绑定器改进

在ASP.NET MVC“第五个预览版”中一个最大的特色投资方面是围绕着表单提交场景所做的工作。上个月，我曾对这些表单提交场景的特性写了一个 很深入的博客贴子。

今天的beta版本包含了这方面的许多另外的改进，这些改进包括：

对复杂类型的内置模型绑定器支持

第五个预览版引进了“模型绑定器（model binders）”的概念，允许你将进来的表单提交值映射到作为Controlleraction方法参数的复杂的.NET类型上。第五个预览版中的模型绑定器是可扩展的，你可以创建自定义的绑定器，在系统的多个层次上将其注册。但第五个预览版并没有随带你可以原样使用的“预制”模型绑定器（所以你不得不建造你自己的绑定器）。今天的beta版现在包含了一个内置的，预先注册的绑定器，可以用来自动地处理标准的.NET类型，而不要求任何额外的代码或注册。

例如，我们可以创建一个象下面这样的带标准属性的Person类：

然后编写下面的代码， 让一个Controller action方法接受其为一个参数变量：

因为上面的参数变量的名称为“person”，在默认情形下，模型绑定器会寻扎表单提交值中键的名称格式是"person.Name","person.Age","person.Email"的值，然后它会用这些值创建和填充一个新的Person对象，然后将其传入我们的action方法。

开发人员也可以使用今天beta版中引进的新的[Bind]特性以及设置其Prefix属性，来改写默认的名称映射逻辑。例如，如果我们将Prefix属性设成“PersonToSave”，绑定器就会在创建Person实例时寻找下列表单值："PersonToSave.Name","PersonToSave.Age", 和"PersonToSave.Email"。你也可以将Prefix设成空白字符，使得绑定器不用前缀而是映射"Name", "Age" 和"Email"：

[Bind]特性允许你指定一个"Included"或"Excluded"属性，可用来对属性进行“白名单（whitelist）”处理而映射到对象上，或“黑名单（blacklist）”处理而不映射到对象上。例如，下面的代码表示我们只想要映射我们person对象的"Name" 和 "Age" 属性：

重要安全技巧：一般来说，你应该非常小心，确保你不允许映射那些你不想被映射的属性。什么时候你有对象上不想被映射的属性，应该总是使用Included/Excluded。例如，假设我们的Person有个Salary（工资）属性，除非我们明确地要终端用户能够设置它的话，我们不想映射它。你应该象这样明确地声明不映射不想要的属性，以免黑客尝试发送假的表单请求，试图发送在用户界面中不能编辑的额外属性信息。

重构的模型绑定器基础设施

Beta版中的模板绑定器系统已经做了显著的重构，你现在可以在建造你自己的定制模型绑定器时，以更细化的方式重用和插入功能。

模型绑定器现在还可以为UpdateModel 和 TryUpdateModel方法所用，允许你编写一个绑定器，然后在ASP.NET MVC中任何处理表单值的地方所重用。

改进了的 UpdateModel 和 TryUpdateModel 方法

UpdateModel 和 TryUpdateModel 方法现在还支持若干个新的选项和重载（包括更丰富的白名单和黑名单选项）。

它现在还支持使用默认的绑定规则调用UpdateModel来填充实例的功能 （在第五个预览版中，你总是需要提供一个白名单，有几个人要求一个能映射所有属性的选项）：

今天的beta版中的另一个新特性是定义你可以用于UpdateModel/TryUpdateModel方法的强类型的白名单过滤器的能力。你可以通过定义一个只含你想要映射的可绑定属性的接口来实现。例如，在下面，我定义了一个IPersonFormBindable接口，其中只有三个属性（而不含Salary属性）：

然后我们可以使用象下面这样的代码来表示我们想要使用这个契约来限制可映射的属性：

这会确保只有那些定义在IPersonFormBindable接口里的属性被映射了，而Salary属性则没有被映射。

改进了的 UpdateModel和TryUpdateModel场景的单元测试

在第五个预览版中，为单元测试使用了UpdateModel 或 TryUpdateModel方法的表单提交场景，你不得不使用模拟（mocking)。今天的beta版本现在则允许你不用模拟，就可以单元测试所有的表单提交场景（从而促成更好的无摩擦单元测试）。

今天的beta版本引进了一个新的IValueProvider接口，模型绑定基础设施用它来获取数值，做绑定（而不是总是从请求对象中获取数据）。FormCollection类（内置于beta版的）实现了这个接口，因此，你现在可以明确地把这个对象的实例传给UpdateModel/TryUpdateModel，来用它的值做绑定。

例如，在下面这个Saveaction方法中，我们将所有进来的表单值绑定到一个 FormCollection上（然后将其作为参数传给该action方法）。然后我可以将这表单集合传给UpdateModel方法，让它使用这个参数将其中的值映射到person模型对象上：

然后我们可以使用下面的代码，单元测试上面这个action方法的一个成功的表单提交场景（注意我们不用模拟任何东西，我们只是创建了一个FormCollection，做数据填充，然后将它作为参数传给action方法）：

然后我们可以用下面的代码单元测试一个不成功的表单提交场景（因为年龄值的输入值不合法，所以失败）。注意我们在一个表单提交失败的场景中，核实了编辑表单会被重新显示（以便用户更正问题）：

我们不用模拟什么就可单元测试上述两种表单提交场景。

强类型的 [AcceptVerbs] 特性

ASP.NET MVC第五个预览版引进了一个新的[AcceptVerbs]特性，你可以用它来表示某个action方法所支持的HTTP动词。

在第五个预览版中，你总是要用字符串来指定动词，在beta中我们依然支持这个用法，但对常用的动词则另加了支持，可用强类型的枚举值来指定。例如：

今天的beta版，不再要求你在象上面那样的场景下同时指定2个action方法的[AcceptVerbs]特性。在默认情形下，ASP.NETMVC现在会寻找一个明确声明支持进来的HTTP动词的action，如果没找到的话，就会使用那个没有明确指定动词的action方法。这可以在常见的GET/POST场景下，省下一些键盘输入（你不再需要修饰GET方法了）。

验证错误信息

很可惜没有能够进入beta版本的一个功能（但会在下一个更新中加入），是对让你从模型类中呈示定制验证错误信息的支持（而不是象你今天能做的，只能在Controller里定制它们）。我们目前正在探究几种支持方式，包括添加对IDataErrorInfo接口的支持，以及对System.ComponentModel.DataAnnotations命名空间下的新的动态数据特性的支持。

但有一个改进倒是进入了今天的beta版，那就是默认的验证错误信息现在对终端用户更加友好了（希望能在许多情形下消除定义定制验证消息的必要性）：

HTML辅助方法的清理

今天的beta版对HTML辅助方法有若干个清理和改进（总的来说，这是个比较棘手的方面，因为要搞对的重载组合是如此之多）.

Html.Form -> Html.BeginForm

今天的beta版中一个可用性方面的变动是，将Html.Form()重新命名为Html.BeginForm()，同时支持它的两个用法，一个利用了using语句，另一个利用了显式的Html.EndForm()辅助方法。我们移到同时支持这2个方法的原因是，围绕着在这个场景下using语句的工作原理，我们在论坛上看到了许多问题/混淆（这个模式对许多开发人员来说并不熟悉）。

下面是2个例子，示范我们是如何通过使用2个不同的表单方式来实现上面的创建屏幕场景的（同时含有验证错误信息的界面）：

方法一： 将using语句用于Html.BeginForm()：

下面的方法使用了VB和C#中的using关键词提供的IDisposable模式，自动终结 </form>：

方法二：明确使用Html.BeginForm() 和 Html.EndForm():

下面的方法使用了一个明确的EndForm()来结束</form>：

开发人员可以使用他们感觉最舒适的方式，在逻辑上，这两个方法做的事是完全相同的。

许多HTML辅助方法改成了扩展方法

在今天的beta版中我们做的一个变动是，把许多HTML辅助方法移动到了System.Web.Mvc.Html命名空间下，并将它们变成了扩展方法（之前，它们只是HtmlHelper类的实例方法）。我们对第五个预览版中的AJAX辅助方法做了类似的变动（它们现在位于System.Web.Mvc.Ajax命名空间下）。

这些变动并不影响视图标识中的intellisense（在默认情形下，我们在web.config文件中自动引用了命名空间，所以还应该跟以前一样，虽然，假如你在把一个应用从第五个预览版移植过来的话，你需要在web.config中自己添加命名空间，请阅读发布说明中的实现步骤）。假如你有单独的类/测试使用了辅助方法的话，确认使用了合适的“using”语句来导入这些命名空间。

我们把辅助方法改成扩展方法，而不是实例方法的原因，是为了给开发人员提供更多的灵活性，来添加/去除/替换我们内置的实现（以及给予我们自己在将来的更多的灵活性）。如果你要覆盖一个方法的HTML实现的话，你现在可以很轻易地实现，同时在你的标识中保持同样的方法代码/签名。

Silverlight / ASP.NET MVC 项目集成

当你在Visual Studio 或 Visual Web Developer 2008 Express中(使用最近发布的Silverlight 2 和 VS 2008 Silverlight 工具)创建新的 Silverlight 2项目时，你现在能够选择ASP.NET网站项目，ASP.NET Web应用项目，现在又多了一个ASP.NET MVC项目来做宿主：

如果你选择这个选项的话，Visual Studio会自动地把Silverlight应用拷贝和部署/更新到ASP.NETMVC应用中去，如果你在IDE里做了改动，并且编译的话。这更方便了开始将基于.NET的Silverlight前端（是在浏览器中运行的）与ASP.NET MVC web 后端集成，从而开拓出更多有趣的新机会。

ASP.NET MVC Futures 程序集

在过去的几个预览版中，ASP.NET MVC的功能被分成了2个程序集，System.Web.Mvc.dll 和Microsoft.Web.Mvc.dll。后面这个程序集以及相关命名空间包含了“futures（将来）”的功能，这些功能还没有被接受在核心的V1产品里发布。当功能成为“被接受”时，我们会将它们从futures程序集中移到核心的程序集中，同时会改变它们的命名空间（从Microsoft.Web.Mvc到System.Web.Mvc）。

以前的预览版在你用文件->新ASP.NETMVC项目菜单项生成新项目时，会自动发布和添加futures程序集。从今天的beta版开始，我们不再自动添加这个程序集，假如你想要用它的话，你需要明确地加入你的项目。这么做的原因，是以便开发人员可以清楚地区别哪些功能会在完全支持的V1产品中（意味着产品支持和在向后兼容性上有更高的承诺），哪些在将来还会演变（也许到下一个版本时才会加到被支持的产品中去）。

重要注意事项：futures程序集（以及其中的源代码）依然会发布，并在ASP.NET MVC V1下工作，如果有什么功能你特别喜欢的话，你不用担心它们会消失(它们还在，你还可以使用它们)。你现在只不过需要明确地引用该程序集，然后在你的项目里使用它罢了。

我们计划在今天稍后发布可用于Beta版的ASP.NET MVC Futures程序集版本。你将可以在这里下载。

/Bin 和 GAC 部署

ASP.NET MVC beta现在同时支持基于GAC的部署（在该方式下，你在一个机器上只安装程序集一次），以及基于/bin目录的部署(在该方式下，你在应用的目录下有一份程序集的拷贝)。

我们会使用GAC启动通过Windows更新的自动服务更新（在这情形下，管理员可以自动对一个机器打补丁，就像现在他们对其他的.NET框架做的那样，而不必更新每个单独的应用）。但基于GAC部署的一个缺点是，对租用主机的场景，它使得部署需要GAC组件的应用来说更困难了，因为一般来说，你在服务器机器上没有管理员权限（而你需要管理员权限才能在GAC中安装组件）。

为确保租用主机场景也能工作（同时确保你不需要你的主机供应商安装任何其他东西（除了ASP.NET 3.5外）就可以让ASP.NET MVC工作），我们还支持将ASP.NETMVC框架程序集部署到你的应用的/bin目录的能力。这将允许你只要将应用xcopy/ftp到服务器上，就可以工作（不需要管理员权限或者特别的安装就可以运行）。但这个做法的一个需要注意之处是，每次服务更新出来的话，你得负责更新程序集，Windows更新不会自动地找到机器上所有的应用目录，为你更新这些程序集。

结语

今天的beta版，向最终的ASP.NET MVC 1.0产品又近了一步。虽然还没有100%的完整功能，但我们认为主要的子系统非常接近完成了，而且目前的品质水平非常好。

我会试着在接下来的几个星期内发布一些更全程（end-to-end）的教程，来展示如何从头使用ASP.NETMVC，然后合乎逻辑地进阶到更丰富的场景。包含在教程列表中的，还有我一直许诺撰写的关于在MVC中使用AJAX的，但一直没发表的贴子（我可是有借口的：Silverlight 2, ASP.NET MVC, .NET 4.0, VS10, 和 Windows7的发布周期都碰巧同时在我的团队平行进行中，很不幸地，我真的是很忙，所以一直耽搁至今）。

就象我一直指出的，如果你不喜欢MVC模型，或者发现对你的开发风格而言不自然的话，你绝对不必使用它。这完全是一个可选项，它并不代替现有的WebForms模型。 WebForms 和 MVC在以后都将被完全支持和增强（.NET 4.0中的ASP.NETWebForms将添加更丰富的URL路径选择功能，更好的HTMLCSS标识支持，对ClientId属性的完全控制，更多的AJAX功能，诸多特性，我不久将在博客中讨论）。所以，如果你不喜欢MVC选项的话，不用担心，不用觉得你应该或者需要使用它，真的不用。

希望本文对你有所帮助，

Scott

标签： ASP.NET, Visual Studio, .NET, Community News, MVC