url来做post操作。 我们也会提供一些对MVC有意识的服务器控件，可以用于没有postback的视图页面里，它们将与基于控制器的逻辑很干净地集成。
2. 【问】MVC框架是否会包括在VS 2008 RTM里?
【答】 MVC框架可以在VS 2008 RTM下工作，我们将在发布VS 2008 RTM的同时，发布第一个预览版。MVC框架本身先会居于一个单独的程序集中，然后会变成.NET 3.5 SP1的一部分。
3. 【问】假如我们使用MVC框架，我们是不是又回到原地了?还是会提供给我们这些认为生命是短暂的人一些适当的好处?用个比喻，我可不想每次冲淋浴，就要重建水龙头(taps)。
【答】注意，MVC框架并不替代现有的web form模型，很明显，我们将继续完全支持并增强web form模型的功能。所有，假如你喜欢控件postback式交互的话，我大概会建议你还是继续目前的做法，使用基于MVP的模型来做测试。
而MVC模型的确在显示HTML方面给你更多的控制。但就象你注意到的，这既有好处也有坏处，好处是你有更多的控制，坏处是，控制越多，你需要照顾的东西也越多。我们将提供很好的方式来处理错误和保持表单状态，这样你就不用写些丑陋的编码来处理这些东西了。对你的界面来说，服务器控件模型还是很好地提供了非常干净的方式来封装视图辅助(view-helper)功能，而且我们将提供一套丰富的控件来辅助你。
4. 【问】Brail视图引擎有一样好处是，视图是独立于主要应用被编译的，所以假如你对视图做了改动，它可以立刻被重新编译。我假定基于DLR的视图没有被编译，但在aspx视图的情形下，改动视图是否需要重新装载应用而导致长时间的延缓呢?假如不需要的话就太好了。
【答】当.aspx网页被改动后， ASP.NET监测到其变化后，会自动为它生成一个新的程序集。那样，我们就不需要重新启动应用了。在基于DLR的.aspx网页的情形下，实际上我们根本不创建程序集，而可以在内存里对它们做编译,基于IronPython的.aspx 网页就是这样工作的。
注意，因为ASP.NET MVC框架是可以插拔的，你可以选用MonoRail Brail视图引擎来显示你的视图。所以如果你喜欢Brail模型的话，还是可以继续和新的MVC框架协同工作的。
5.【问】对MVC有意识的服务器控件能否可以从模型验证来推出自动的客户端验证(譬如通过CSS属性)?
【答】我们会研究，在可能的情况下，从模型的验证，来允许处理错误的客户端样式和客户端javascript错误验证。但这个不会出现在几个星期后的第一个预览版里，但这是我们近期看过的，以后会再研究。
6.【问】你是可以讨论一下MVC中DLR，动态语言，LINQ和Asp.Net futures的支持?
【答】LINQ肯定会在MVC框架内完全支持，我们也会增加DLR支持，允许你使用包括IronPython和IronRuby在内的动态语言建造视图和控制器。
7.【问】象UpdatePanel和其他依赖于postback模型的跟AJAX有关的特性将会得到什么样的支持?
【答】UpdatePanel确实使用postback，所以你无法直接在基于MVC的视图里使用那个控件。但我们将提供一个跟该控件类似功能的控件以及相关的辅助方法。它会调用控制器的一个方法，允许你非常容易地做局部更新。它将允许你非常轻松地使用ASP.NET AJAX库。在几个星期之后我会写博客讨论更多细节。
8.【问】你的讲座录像里的视图代码看上去非常危险地象是老的asp(没有.net)。monorail nvelocity也是如此。我希望你能综合两者的好处哦。
【答】有些人喜欢<%= %>模型，在alt.net大会上我演示MVC模型讲座的参与者都要我使用这种方法(所以我写了那样的代码)，我也可以使用来做列表，通过code-behind来做数据绑定，这允许你更清晰地构造你的视图显示代码。
9.【问】我只是好奇，你需要对内层代码做多少改动才能使得声明式服务器控件在不使用postback模型的情形下工作?ASP.NET MVC会在没有
