微软最新ASP.NET MVC框架Beta版技术细节(5)

验证错误信息

很可惜没有能够进入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模式，自动终结 ：

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

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

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

许多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.NET MVC应用中去，如果你在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.NET MVC项目菜单项生成新项目时，会自动发布和添加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.NET MVC框架程序集部署到你的应用的\bin 目录的能力。这将允许你只要将应用xcopy/ftp到服务器上，就可以工作（不需要管理员权限或者特别的安装就可以运行）。但这个做法的一个需要注意之处是，每次服务更新出来的话，你得负责更新程序集，Windows更新不会自动地找到机器上所有的应用目录，为你更新这些程序集。

结语

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

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

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

希望本文对你有所帮助，

【编辑推荐】

1. 跟ASP.NET MVC一起使用jQuery
2. ASP.NET开发中的八个最佳实践
3. 探讨ASP.NET MVC框架内置AJAX支持编程技术