我刚刚听了 StackOverflow 团队的第 17 期播客，他们对ASP.NET MVC 评价很高，我决定去看看。
但首先，我想确定这是值得的。我已经为几天后开始的项目创建了一个基础 Web 应用程序（供其他开发人员在此基础上构建），我想根据您的经验了解是否应该花时间学习 MVC 的基础知识并重新创建使用此模型的基本 Web 应用程序。
真的有大的优点值得吗？
编辑：这不是一个现有的项目，它是一个即将开始的项目，所以如果我要这样做，它应该是现在......
我刚刚发现了这个
但是，它不使用现有的回发模型与服务器进行交互。相反，您会将所有最终用户交互路由到 Controller 类 - 这有助于确保关注点和可测试性的清晰分离（这也意味着基于 MVC 的视图没有视图状态或页面生命周期）。 p>
这将如何运作？没有视图状态？没有活动？
【问题讨论】：
标签： asp.net-mvc
如果您今天对 WebForms 非常满意，那么也许 ASP.NET MVC 不适合您。
很长一段时间以来，我一直对 WebForms 感到沮丧。我绝对不是一个人在这里。 Web 上的智能客户端、有状态抽象在复杂场景中严重失效。我碰巧喜欢 HTML、Javascript 和 CSS。 WebForms 试图对我隐藏它。它也有一些非常复杂的解决方案来解决实际上并不复杂的问题。 Webforms 本身也很难测试，虽然您可以使用 MVP，但它对于 Web 环境来说并不是一个很好的解决方案......（与 MVC 相比）。
如果... - 你想更好地控制你的 HTML - 想要像其他平台一样的无缝 ajax 体验 - 想要彻底的可测试性 - 想要有意义的 URL - 讨厌处理回发和视图状态问题
而对于Preview 5的框架，还是比较稳定的，设计也差不多，升级也不难。我在预览版 1 上启动了一个应用，并在最新预览版发布后的几个小时内完成了升级。
【讨论】：
重要的是要记住，MVC 和 WebForms 不是竞争的，而且一个并不比另一个好。它们只是不同的工具。大多数人似乎将 MVC 与 WebForms 视为“一个必须比另一个更好”。那是错的。一个是锤子，另一个是螺丝刀。两者都用于将事物放在一起的过程中，但具有不同的优势和劣势。
如果有人给你留下了不好的印象，你很可能是想用螺丝刀敲钉子。使用 MVC 变得优雅和简单的 WebForms 的某些问题很麻烦，反之亦然。
【讨论】：
我用过 ASP.NET MVC（我什至写了一个 HTTPModule 让你在 web.config 中定义路由），但我仍然对此感到苦涩。
这似乎是组织和生产力方面的一大步。也许它不适合某些人，但我已经弄清楚了网络表单，就使它们可维护而言，它们对我没有任何挑战。
那，我不赞同当前的“测试一切”时尚......
【讨论】：
ASP.NET MVC 基本上允许您分离代码不同部分的职责。这使您能够测试您的应用程序。您可以测试您的视图、路由等。它还可以加速应用程序，因为现在没有 ViewState 或 Postback。
但是，也有缺点。由于您没有使用 WebForms，因此您不能使用任何 ASP.NET 控件。这意味着如果您想创建一个 GridView，您将运行一个 for 循环并手动创建表。如果您想在 MVC 中使用 ASP.NET 向导，那么您必须自己创建。
如果您厌倦了 ASP.NET 网络表单并希望自己执行所有操作，这是一个不错的框架。但是您需要记住，您是否会从再次创建所有内容中受益？
总的来说，我更喜欢 Webforms 框架，因为它有丰富的控件套件和自动管道。
【讨论】：
我会先创建一个测试站点，看看团队的想法，但对我来说，使用 MVC 后我不会再回到 WebForms。
有些人不喜欢将代码与 HTML 混合，我可以理解这一点，但我更喜欢页面生命周期、呈现 HTML 和对我来说很大的灵活性 - 页面源中没有嵌入视图状态。
有些人更喜欢 MVC 以获得更好的可测试性，但我个人的大部分代码都位于中间层，并且无论如何都易于测试......
【讨论】：
@Juan Manuel 你曾经在经典 ASP 中工作过吗？当您必须编写自己的所有事件和“viewstatish”项目（例如在提交表单后调用其选定值的下拉菜单）时？
如果是这样，那么 ASP.NET MVC 就不会感到那么尴尬了。我会查看 Rob Conery 的 Awesome Series “MVC Storefront”，他一直在浏览框架并为店面站点构建每个预期的组件。这真的很令人印象深刻，而且很容易跟上（追赶是很困难的，因为 Rob 一直很活跃，并且在那个系列中发布了很多内容）。
就个人而言，与 Jeff Atwood 的 feelings on the topic 完全相反，我更喜欢网络表单模型。这肯定与 vbscript/经典 ASP 时代完全不同，但实际上，检查视图状态并编写自己的 CSS 友好控件是令人愉快的。
然后，请注意我说的是“喜欢”。 ASP.NET MVC 真的很棒，与其他的 Web 技术更相似。如果您喜欢或需要在多个平台上工作，从 ASP.NET MVC 转移到 RAILS 肯定更容易。虽然，是的，如果您的公司不允许任何颜色的“测试版”软件，它显然非常稳定（这个站点）；此时将其实施到生产中可能是一个问题。
【讨论】：
@Jonathan Holland 我看到你被否决了，但这是一个非常有效的观点。我一直在阅读一些关于 intertubes 的帖子，其中人们似乎混淆了 ASP.NET MVC the framework 和 MVC the pattern。
MVC 本身就是一个设计模式。如果您正在寻找的只是“关注点分离”，那么您当然可以使用网络表单来实现。就个人而言，我是标准 n 层环境中 MVP pattern 的忠实粉丝。
如果您真的想在 ASP.NET 世界中完全控制您的标记，那么 MVC 框架就是为您准备的。
【讨论】：
如果您是一名专业的 ASP.NET 开发人员，并且有时间学习新东西，我当然建议您花一些时间尝试 ASP.NET MVC。它可能不是你所有问题的解决方案，并且有很多项目可能会从传统的 webform 实现中受益更多，但是在尝试弄清楚 MVC 时你肯定会学到很多东西，它可能会带来很多想法你可以申请你的工作。
我在尝试开发 MVC 宠物项目时浏览了许多博客文章和视频教程时注意到的一件好事是，它们中的大多数都遵循当前的最佳实践（TDD、IoC、依赖注入，以及在较低程度上POCO)，加上大量的 JQuery 让用户的体验更有趣，这是我可以在我当前的 webform 应用程序中应用的东西，而且我以前没有这么深入地接触过。
ASP.NET MVC 的做事方式与 web 表单是如此不同，以至于它会让你有点动摇，这对开发人员来说是非常好的！
OTOH 对于 Web 开发的初学者来说，我认为 MVC 绝对是一个更好的开始，因为它提供了开箱即用的良好设计模式，并且更接近 Web 的实际工作方式（毕竟 HTML 是无状态的）。在 MVC 上，您决定在线上来回传输的每个字节（至少在您不会对 html 助手发疯的情况下）。一旦这个人明白了这一点，他或她将能够更好地转移到 ASP.NET 网络表单和服务器控件提供的“人工”设施。
【讨论】：
如果您喜欢使用为您完成大量工作的服务器控件，您将不会喜欢 MVC，因为您需要在 MVC 中进行大量手动编码。如果您喜欢 GridView，可以自己编写或使用其他人的。
MVC 并不适合所有人，特别是如果您不喜欢对 GUI 部分进行单元测试。如果您对 Web 表单感到满意，请继续使用它。 Web Forms 4.0 将修复当前的一些缺点，例如由 ASP.NET 自动分配的 ID。您将在下一个版本中控制这些。
【讨论】：
除非与您合作的开发人员熟悉 MVC 模式，否则我不会。在做出如此大的改变之前，我至少会先与他们交谈。
【讨论】：
我正在尝试对 ASP.NET MVC 做出同样的决定，Juan Manuel。我现在正在等待合适的小型项目出现，我可以进行实验。如果实验进展顺利——我的直觉认为它会——那么我将围绕框架构建我的新大型项目。
使用 ASP.NET MVC，您将失去 ASP.NET Web 窗体的视图状态/回发模型。如果没有这种抽象，您将更紧密地使用 HTML 以及 HTTP POST 和 GET 命令。我相信 UI 编程在一定程度上是朝着经典 ASP 的方向发展的。
伴随着这种不便，带来了更大程度的控制。我经常发现自己与 ASP.NET 的伪会话垃圾作斗争，重新获得对输出 HTML 的完全控制的前景似乎令人耳目一新。
这可能是最好的——或最坏的——两全其美。
【讨论】：
我不知道 ASP.NET MVC，但我非常熟悉 MVC 模式。在没有 MVC 的情况下，我看不到另一种构建专业应用程序的方法。它必须是 MVC 模型 2，如 Spring 或 Struts。顺便问一下，你们是如何在没有 MVC 的情况下构建 Web 应用程序的？当您遇到每个请求都需要某种验证的情况时，例如验证用户是否经过身份验证，您的解决方案是什么？每个页面中都有某种 include(validate.aspx)？
您从未听说过 N 层开发吗？
【讨论】：
Ajax、RAD（带有 ajax 的 Web 表单通常是反 RAD）、完全控制（无需开发大量代码和循环）。网络表单仅适用于绑定一些网格等，而不适用于其他任何东西，还有一件更重要的事情 - 性能。当你陷入网络表单的地狱时，你迟早会打开 MVC。
【讨论】：
我不建议只对现有项目进行切换。也许启动一个小型“演示”项目，团队可以使用该项目来试验该技术并（如有必要）了解他们需要什么并向管理层证明进行转换是值得的。最后，即使是开发团队也可能会意识到他们还没有准备好或者不值得。
无论你做什么，一定要记录下来。也许如果您使用演示项目，请写一个事后分析以供将来参考。
【讨论】：
我不知道 ASP.NET MVC，但我非常熟悉 MVC 模式。在没有 MVC 的情况下，我看不到另一种构建专业应用程序的方法。它必须是 MVC 模型 2，如 Spring 或 Struts。顺便问一下，你们是如何在没有 MVC 的情况下构建 Web 应用程序的？当您遇到每个请求都需要某种验证的情况时，例如验证用户是否经过身份验证，您的解决方案是什么？每个页面中都有某种包含（validate.aspx）？
【讨论】：
不，你不应该。随意尝试一个新项目，但是很多熟悉 ASP.NET 网络表单的人还不喜欢它，因为不得不处理原始 HTML + 许多不同的概念 + 对文档的选择非常少/教程。
【讨论】：
ASP.net MVC 仅在“Preview 5”中的事实是否会在调查时引起关注？
我知道 StackOverflow 是使用它创建的，但微软是否有可能在它正式退出 beta/alpha/preview 版本之前对框架进行重大更改？
【讨论】：
如果你死心塌地使用 MVC 框架，那么我宁愿开始使用 Castle 项目的框架...
话虽如此，我个人认为 WebControl 有很多优势，例如能够创建具有状态客户端的事件驱动应用程序等等。大多数反对 WebControls 的论点都是因为缺乏对 WebControl 模型等的理解而构建的。而不是因为它们实际上真的很糟糕......
MVC 不是灵丹妙药，尤其是 Microsoft MVC...
【讨论】：
我见过一些 MVC 框架的实现，为了可测试性，有人用代码渲染了整个 HTML。在这种情况下，视图也是可测试的代码。但我说，我的朋友，将 HTML 放入代码中是一场维护噩梦，他说我喜欢所有编译和测试的东西。我没有争辩，但后来发现他确实把这个HTML放到了资源文件中，然后疯狂继续……
他几乎没有意识到分离View的整个想法也解决了维护部分。它在某些应用程序中超过了可测试性。如果我们使用 WYSWYG 工具，我们不需要测试 HTML 设计。出于这个原因，WebForms 很好。
我经常看到人们滥用回发和视图状态并将其归咎于 ASP .NET 模型。
请记住，最好的网页仍然是 .HTML，这就是 ASP .NET MVC 的强大之处。
【讨论】：