采访与书摘：ASP.NET MVC in Action

今天，InfoQ 发布了《 ASP.NET MVC in Action 》一书的书摘（PDF）同时也采访了此书的作者 Jeffrey Palermo 、 Ben Scheirman 和 Jimmy Bogard 。

《ASP.NET MVC in Action》详细讲解了 ASP.NET MVC 框架，并使用本书作者编写的开源项目 http://codecampserver.com 作为贯穿全书的示例。除了 ASP.NET MVC 框架本身，作者还介绍了 Onion Architecture、领域驱动设计（DDD)、测试驱动开发（TDD)、控制反转（IoC）以及其它一些真实项目中经常用到的类库（和技术）。

本书章节如下：

• ASP.NET MVC 框架入门
• 深入理解模型（Model）
• 深入理解控制器（Controller）（可在 InfoQ 下载）
• 深入理解视图（View）
• URL 路由
• 定制和扩展 ASP.NET MVC
• 为复杂网站设计可扩展架构
• 使用现有的 ASP.NET 特性
• ASP.NET MVC 中的 Ajax
• 托管与部署
• MonoRail 和 Ruby on Rails
• 最佳实践
• 范例

使用优惠代码infoq35从 Manning 购买此书，即可获得 35% 的折扣。

InfoQ：你写 ASP.NET MVC in Action 这本书的原因是什么？

Jeffrey：自从 2007 年 3 月起，我就做为顾问参与了 ASP.NET MVC 的开发工作。我发现，这个 ASP.NET 的简化版本中，蕴藏着巨大的商机。于是，我决定让 HeadSpring Systems（注：Jeffery 是 HeadSpring Systems 的 CTO）向 ASP.NET MVC 靠拢，而不是继续使用 Castle MonoRail 和 WebForms。在框架正式发布前，我们就积累了一些使用经验，并在如何正确使用这个框架上学到了很多。而得益于代码优先的构建方式，你很容易就可以（为框架）编写可重用并可重载的组件。我编写这本书的动机来源于 Alt.NET 社区。这是一个极其注重开发质量和速度的社区。通过一本由 Alt.NET 社区成员编写的，并带有他们想法的书，读者可以快速掌握 ASP.NET MVC。并且，广大的.NET 社区也可以从中学习一种不同的.NET 开发方法，虽然目前还不是主流，但是发展迅速。

Ben：ASP.NET MVC 刚刚出现的时候，我就对它产生了兴趣。我已经很久没有因为微软的产品而这么激动了。我决定要深入挖掘一下这个框架，尽可能的提供反馈，并与其它开发人员分享我的发现。所以当 Jeffery 找我一起编写此书时，我马上就同意了。那是一个漫长的，令人厌倦的经历，但也是令我难忘的美好回忆。

Jimmy：这么多年来，我读过很多优秀的和糟糕的技术书籍。有些书是讲解特定框架或技术的，其中非常让人失望的是，它们会对 API 和扩展点描述的非常详细，但是却不告诉你“什么时候”以及“为什么”使用这些东西。当 Jeffrey 找到我来写这本书时，他很明确的告诉我，这本书是为和我们一样的读者写的。在每天的工作中，我们会使用像领域驱动开发这样的概念，以及像测试驱动开发这样的实践。而在.NET 世界中，将这些概念合并到一本讲解 Web 框架的书中，是非常少见的事。

InfoQ：现在很多 ASP.NET 项目都使用了 MVP 或类似的模式，这对迁移到 ASP.NET MVC，是否有所帮助？

Jefffey：有帮助。任何时候，如果你可以将代码从不属于你的框架中分离出来时，都是件好事。但是，如果你唯一的目的就是迁移到 MVC 的话，MVP 并不会带来直接的好处。你可以先从在 WebForms 项目中引入 MVC 页面开始，这比较容易，而且网上有也很多相关的教程。

Ben：在 WebForms 项目中广泛使用 MVP 后，我意识到，为实现 MVP 所做的工作并不总是值得的。你很难让初级程序员理解“为什么”使用 MVP，特别是当他们看到 Visual Studio 的一些拖拽功能的演示后。在 WebForms 中，页面对（HTTP）请求拥有主控制权，你只能选择 MVP 模式来有意识的将展现逻辑委托给 presenter。MVP 本身是一个可行的模式，而且在很多场合下都适用，但在 WebForms 中，我感觉有太多的问题，我认为在 ASP.NET 中这不是一个好的方式。

Jimmy：理论上来说，是有帮助的。MVP 支持分离关注点，你可以通过 Uncle Bob 的 SOLID 原则来理解，为什么 MVC 比 WebForms 更值得关注。但是，从技术上来说，并不是这样的。ASP.NET MVC 对并行开发和部署提供了无缝支持，但 control 和 page 模型却无法很好的转换为 controller-view 模型。 MVC 中不存在这样的问题。MVC 模式天生就是可测试的，而且鼓励对关注点的分离。当然，你必须保证不让你的 controller 太胖（包含太多东西），但是你很容易向初级程序员解释“为什么”。对于 ASP.NET 来说 MVC 是一个更好的模式集。

InfoQ：在书中，你提到可以混合使用 ASP.NET 和 ASP.NET MVC。对于那些希望迁移到 ASP.NET MVC 的 ASP.NET 项目，这是推荐的方式么？

Jeffrey：是的，虽然这是特殊情况。你不会希望永远有一半页面是 WebForms，而另一半是 MVC。将成百的 WebForms 页面转换成 MVC 的工作量是非常巨大的。如果你的应用程序已经能够满足用户的需求，那就需要考虑一下，为迁移所花费的成本可能并不值得。但是，如果你刚刚开始开发，只有很少的 WebFroms 页面，那么迁移的成本就很低了，MVC 会很快回报你的投资。如果你正在计划从 WebForms 迁移到 ASP.NET MVC，那就需要做一个全面迁移的计划。程序需要保持自身的一致性，在程序中做每件事都只能有一种方式。

Ben：你可以创建一个新的 ASP.NET MVC 项目，将以前的 WebForms 页面放在一个不同的子目录下（需要在 Views 目录外）。然后将这个目录放到 IgnoreRoute 中，就可以继续使用 ASP.NET 的机制了。 你也可以在 WebForms 项目中添加 MVC 页面，这或许更费功夫，但还是可以的。

Jimmy：对于大项目来说，这可能是唯一可行的办法。很少有人能为新项目上线等上 12 个月或更长时间，同时还停止向已有系统上添加任何功能。由于 web 本身就是非耦合的，可以在不影响用户总体体验的基础上替换系统的部分功能。但是，对于那些已经在自定义控件和基础结构上投入了大量时间和金钱的公司来说，这些部分并不能很好的转化为 controller 和 view。相反，这些公司可能需要用 portable areas、JQuery 插件、partials 等技术重新开发这些公共模块。

InfoQ：如果你可以修改 ASP.NET MVC，哪一部分是你最想修改的？

Jeffrey：Html helper。已经有太多用于创建 input 元素的重载方法了，框架需要在未来的很多年中对此提供支持。我希望框架仅仅为每个 input 提供一个方法，并让社区或程序自己编写其它的方法。现在，当开发人员输入“Html.”时，就会看到一个长长的列表，而你可能只会用到其中的 10 个。

Ben：我一致认为 WebFormsViewEngine 不好用。我更喜欢 Spark，我希望它能包含在“正式版”中，甚至是默认的（视图引擎）。 Spark 拥有更好的模版语法，还有智能提示（intellisense），这非常有用。

Jimmy：很明显，Rails 成功的主要原因是使用了动态语言－Ruby。在 ASP.NET MVC 中，你会发现很多地方如果使用动态语言会带来非常大的好处，但是开发人员却只能用不那么直接的方式来实现。在.NET 社区中，并没有多少人大声要求对动态语言的支持，因此也就没有多少习惯了静态语言的人能够了解动态语言所带来的好处。当然，一个还不错的视图引擎和一个类似 Rails ActiveRecord 的集成数据访问结构也是有帮助的。

InfoQ：对于已经有 ASP.NET 经验的开发人员，你有什么建议来帮助他们迁移（到 ASP.NET MVC）么?

Jeffrey：ASP.NET MVC 是对 IHttpHandler 的另一个实现。你应该尽可能的去利用它，但同时也要尽可能的远离它，就像对其它框架一样。在 controller 里只写最少的代码，而将其他的代码放在你自己的类中。记住，随着技术的发展，迟早你会再把 ASP.NET MVC 程序迁移到其它的框架中。与 controller 或其它框架部分绑定的代码越多，就越难迁移。最后，一定要利用 MvcContrib，它是一个构建在 MVC 框架之上的开源库。

Ben：看我们写的书：）严肃的讲，有 ASP.NET 经验的开发人员必须要“忘记”使用 WebForms 时的一些坏习惯。例如，很多聪明的 ASP.NET 开发人员，对与 HTML 的工作机制一点也不了解，因为都被 WebForms 隐藏起来了。这些开发人员需要拥抱 HTML 和 HTTP，从其它 Web 框架中学习，如 Django 和 RoR，看看和 WebForms 有什么不同。然后，他们就会对为什么选择 ASP.NET MVC 有更好的理解。

Jimmy：尽快忘记 ASP.NET 的页面生命周期。ASP.NET 试图让开发人员无须了解 HTML、CSS、JavaScript 和 HTTP 这些构成 web 的基础构件。当迁移到 MVC 时，理解这些基础构件非常重要。幸运的是，那些不使用 ASP.NET 进行 web 开发的人，几乎都在使用某种 MVC 框架，因此有很多相关的资料。一本讲解 CSS、JavaScript、JQuery 和 HTML 的好书非常有用，而且不会局限于特定的服务器端技术。

InfoQ：你可以在 ASP.NET MVC 中使用多种试图引擎，当选择其它试图引擎时，需要考虑哪些方面?

Jeffrey：要考虑长期的可维护性。你需要选择一个会被广泛采用和支持的视图引擎，而且需要有完备的工具支持。视图引擎就是框架的另一种形式。对于开发人员来说，使用任何新的框架都需要一定的成本。

Ben：对于某些视图引擎（比如 Spark），将内容放在页面的不同区域是非常简单的。比如说，你想开发一个 widget，需要将样式表放在 head 标签内，这很容易做到。 如果你想将视图打包在程序集中，以便可以分发（像第三方组件那样），Spark 也有内建的嵌入式模版提供支持。

最后，需要注意的是，你不是只能用一个视图引擎。你可以根据不同的场合，混合使用，以达到最好的效果。

Jimmy：视图是一项投资，一旦决定使用某个视图引擎，就很难反悔了。不过，MVC 提供了很多扩展点，其中一些是特别为视图开发而设计的。 WebForms 引擎是从 ASP.NET 延续下来的，在标记中混合 C#代码不是件好事，相反你应该开发控件。根据你的系统的紧急程度，以及将来谁会维护它，关注其它视图引擎社区的活跃程度，可以让你了解其它选择的可行性。

InfoQ：ASP.NET MVC 2 离我们越来越近了，对于目前的 beta 版本，你有什么看法?

Jeffrey：这个版本非常棒。它会被包含在 VS 2010 中，这非常好。而且这个版本仍然不是.NET Framework 的一部分，这意味着它可以比 framework 更新的更快。而最重要的特性莫过于 Area 了。Area 在.NET 4 中会成为 ASP.NET MVC 的组件模型。你可以在一个 dll 中发布一对 controller/view 或多个页面组成的组件。Html.EditorFor 和 Html.DisplayFor 也计划包含在其中，不过这可能对于 2010 年 3 月的发布时间来说，有些太多了。

Ben：这个版本不是太惊人。我认为这个框架又前进了一大步，我相信这个版本为以后的开发建立了良好的基础。我对于新的 Display 和 Editor 模版非常期待。

Jimmy：在 MVC 1 中，从新建项目开始，直到获得一个可用的系统需要走很长的一段路。我们需要做很多工作来得到期望的结果。这包括自己编写强类型视图、区域、强类型 HTML 构造器、验证等等。我们非常期望目前的 beta 版本可以避免所有这些需要自己编写的代码。

InfoQ：在结束之前，对这本书和 ASP.NET MVC 还有什么需要补充的么？

Jeffrey：这本书包含了真实项目的经验，这些项目可以追溯至 2008 年 7 月，也就是 ASP.NET MVC 发布前的整整 9 个月。目前，我们正在编写 ASP.NET MVC 2 in Action，并计划于 3 月出版发售。 我们计划将此书放在 http://github.com/jeffreypalermo/mvc2inaction 进行公开编写，欢迎大家对本书的代码进行评估和改进。

Jimmy：ASP.NET MVC 中的很多概念，和其他 MVC 框架基本一致，比如 Django 和 Rails，这也是 ASP.NET MVC 的一个重要的卖点。这意味着，MVC 开发人员面对的问题，可能在其它社区已经解决了。搞清楚哪些是其它框架和社区已经支持的，并将之引入到.NET 社区，是非常有益的。

InfoQ：非常感谢。

查看英文原文： Interview and Book Excerpt: ASP.NET MVC in Action 。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。