在我看来，似乎有很多事情正在进行，每个人都加入了 MVC 的潮流。 几乎每个人都在毫无说服力地宣称 WebForms 是邪恶的和撒旦的。然后他们继续说控件是邪恶的，它们不应该出现在 Web 应用程序中。如果没有任何控件，您将如何显示任何内容？
我记得当 WebForms 第一次问世时，每个人都喜欢它们。我猜几年后，人们会继续关注下一件事并宣布 MVC 是邪恶的，因为您必须实际创建控件才能使用 MVC，他们会说您必须开发应用程序而不用担心控件。
我认为 MVC 可以在 WebForms 中通过不在 Form 标签中包含 RunAt 来实现。 然后，如果您想检索数据，只需使用 Ajax。
谁能说服我为什么应该使用 MVC 而不是 WebForms？
【问题讨论】：
标签： asp.net-mvc webforms
WebForms 是一个很棒的框架，但它确实需要您深入了解它。是的，您仍然应该是 HTML 和 JavaScript 方面的专家。我所听到的关于 WebForms 的每一个抱怨都来自那些没有花时间去理解 WebForms 的人。以下是我对其中一些的回答。
ViewState 是邪恶的，会减慢页面速度
这让我想起了将所有东西都设为全局变量的程序员。你当然可以这样做，但你不应该！ WebForms 和 ViewState 也是如此。除非需要，否则不要使用 ViewState，而且要谨慎使用。将 1000 个字符的视图状态添加到 html 并没有错，如果它会带来更好的用户体验和/或加快开发时间。您可以在 MVC 中通过使用数百个隐藏的输入控件乱扔页面来遇到相同的问题，是的，我已经看到了。顺便说一句，ViewState 并不“神奇”，它只是将一些数据存储在单个输入控件中，并对其进行加密以达到良好的效果。
WebForms 生成“丑陋”的 html 并且到处都是长 ID
嗯，首先，实际上没有人会查看生成的 hmtl（例如，您是否查看过 google.com，它是一团糟？！）。其次，如果您真的关心生成特定的 html，只需不到一个小时就可以使用您选择的 html 创建您自己的可重用组件或控件。或者，您可以采用现有控制，覆盖渲染并改用该控制。再一次，你必须知道去哪里以及如何去做，但是一旦你知道了，这将是一个巨大的生产力提升，没有任何牺牲。自动生成长 ID 以确保整个页面的唯一性。如果您有机会开发复杂的 MVC 视图，您会注意到您将发明自己的长 id 模式，以便在发布时正确解析表单字段。
WebForms 不允许每页有多个表单
我已经开发了 10 年，只有一次我需要多个表单。然后我发现我没有。您确实必须了解 HTTP 请求和响应以及如何使用 WebForms 来实现它们，但如果您这样做了，您将永远不需要多个表单，也根本不会考虑“表单”。
WebForms 页面不可测试
绝对不是真的。即使您不喜欢 MVP（我不喜欢），也有其他技术可以测试您想要测试的任何内容。确实，如果您只是按原样使用 WebForms 中的页面并将所有逻辑隐藏在代码中，那么它可能无法测试，也不是一个好主意。但是，就像在 MVC 或 Windows 窗体应用程序中一样，您可以而且应该至少对于复杂的视图创建中间层，例如视图和控制器。我更喜欢将功能封装到实现接口或继承基类的用户控件中。然后用户控件所在的页面就像一个“主控制器”。在这种情况下，可以测试单个视图或用户控件，因为它们都实现了接口或基类。
JavaScript 很难在 WebForms 中实现
JavaScript 实际上在 WebForms 中比在 MVC 中更容易实现。你肯定有更多选择！但是再一次，您必须非常了解 WebForms 才能实现这一点。在 WebForms 中，您可以“注入”带有可重用组件和控件的 javacript。或者您可以在更改页面上的设置以保持 ASP 实现 id 命名方案后，像在 MVC 或纯 HTML 中一样使用它。
说了这么多，WebForms 有什么 MVC 没有的？在我看来，表示组件的封装和可重用性是迄今为止最大的。对于复杂的视图，我开发单独的组件（服务器或用户控件），然后自定义控制器或表示工厂将它们全部编织到位。此外，WebForms 中的设计时 html 比 MVC 中的要干净得多，这使得经过适当培训的图形设计师更容易进行设计和样式设计。它更干净，因为在设计时 html 中没有编程代码，只有标记（我不使用数据绑定表达式）。当然，在 WebForms 中进行原型设计要容易得多。对于原型，我通常会忽略所有最佳实践，而求助于向导和直接访问数据库的丑陋代码隐藏代码。
我可以继续说下去，但我想说的主要一点是，WebForms 和 MVC 是非常不同的模式，需要不同的知识和思维方式来提供出色的解决方案。两者都需要尽可能多的 Web/HTTP/CSS 知识。如果我必须对高流量的公共网站（例如博客）提出一项建议，但并非总是如此，我可能会倾向于 MVC。对于复杂的 Web 应用程序，无论是内部/Intranet 还是会员外部/Internet 应用程序，我都会倾向于 WebForms。
【讨论】：
这是一个愚蠢的讨论 - 它们是不同的，ASP.NET MVC 和 WebForms 是不同的技术！我在所有新项目中都使用 MVC，但是当我需要 RAD 时，我会使用 WinForms，因为它很简单，并且已经有很多大师编写的控件。
别再讨论这个了。谁想了解差异？只需尝试这两种技术，您就会自己理解。
【讨论】：
这里有几个更详细的答案，所以我不会重复他们所说的任何内容，我会尽量让我的答案更简洁一些。你不应该，一定要使用 MVC 而不是 webforms，就像你不应该使用 webforms 而不是 MVC - 它们都是工具，或多或少地适用于不同的情况。几年前，我在 J2EE 上第一次接触到 MVC，当时 .NET 刚刚问世（我不确定当时 ASP.NET MVC 是否可用）。它提供了一个非常好的、干净的框架并提供了更多的“web”应用程序（即请求/响应），但是您还可以使用 AJAX 添加更多的客户端功能——我在 php 上使用 AJAX 做了一些非常时髦的事情我前段时间写的应用程序，在 MVC 下都可以使用。
有些事情 MVC 做得更好，有些事情 webforms 做得更好，但如果你不了解这两种技术，你就无法为你正在做的当前项目选择最好的技术，所以请不要这样做对自己有害 - 去学习 MVC。即使您从不直接使用它，它仍然可以为您提供有用的“理论”知识，您可以将其应用于其他工具。我尝试尽可能多地学习不同的东西，因为我的弓弦越多，我无法解决问题的可能性就越小（例如，在那个 php 应用程序中，我使用了 php，连接到一点 ASP，甚至让 DOS 和 *NIX 批处理/脚本文件执行某些功能 - 每个工具都有自己的位置，最适合分配给它的工作）。
【讨论】：
您不应该随意选择其中一个；不要仅仅因为 MVC 框架是新来的，而且每个人都在赞美它，特别是如果你对使用 Web 窗体做事感到满意，就不要对 MVC 框架感到满意。几乎所有现有系统都将使用更老、更成熟的技术，这并没有错。
虽然 MVC 框架确实允许更轻松地分离关注点（毕竟，这就是 MVC 模式的用途），但它也带来了编写更多 HTML 的责任，我认为理解得更深入一些网络如何运作；不一定是不合理的要求，但您可能会争辩说，在您开始使用它的最初几次时，它会稍微减慢您的速度。
老实说，我同意 Web Forms 有很多不应有的批评。诚然，在后台发生了很多神奇的事情，并且您对某些 HTML 输出的控制较少，但使用 CSS 设置样式并非完全不可能（您最终可能会大量使用 !important），而且它是即使它不符合纯粹主义者对可能是什么的看法，也并非不可能获得一些关注点分离。你仍然可以使用 MVC 框架编写非常糟糕的代码。如果您希望快速组合一些东西，并且您擅长 Web 表单，那么您将能够非常快速地实现这一目标，这没什么好羞耻的，不是吗？
当然，这并不是说您也应该坚持己见而忽略 MVC。它是一个很好的框架（事实上，它是一个非常 很好的框架），它确实提供了一些您可能希望从长远来看可以利用的好处。您还必须记住，它也不会自动取消您了解的有关 ASP.NET 2.0 的所有内容。许多支持架构都包含在 MVC 框架中，包括成员资格提供程序之类的东西。
【讨论】：
我认为部分问题在于许多人没有意识到 MVC 不是 M$ 发明，也不是 Web 表单的替代品。当然，人们喜欢“新”事物，并且喜欢到处乱说流行语，尤其是为了改进他们的简历……
最后，.NET 开发人员有了一些选择，而有了这个选择，他们就会对他们做出的决定承担一定程度的责任。许多网络表单开发人员对这一责任感到紧张，我并不感到惊讶。它以前不在那里。最终，它可以让你成为一个更好的开发者，或者一个更差的开发者。现在由您决定。
人们喜欢网络表单，因为它比 ASP（经典）更好。是的，在 5 到 10 年内，我确信比我聪明得多的某个人/团体将发展出一种新的范式/模式。
小心使用绵羊标签，在某种程度上，通过坚持供应商特定的模式（网络表单），您可能是一只更大的“绵羊”。
MVC 现在跨各种平台，这意味着您开发有意义且稳定的问题解决方案的潜力可以大大增加。或减少。这最终取决于你。如果你还没有准备好，那就等待 ASP.NET MVC 成熟。但是不要对任何事情闭上思绪，尤其是已经非常成熟的模式！
我推荐阅读 Rob Connery 的 extremely inflammatory blog。他肯定用手指拨弄着我的疼痛！然后去阅读 RoR 的东西、Cake 和 Struts。所有这些都将开始向您展示将 MVC 引入 .NET 的人的愿景（~ish），并希望能激发您以不同的方式看待问题！
【讨论】：
我认为 MVC 的主要优势如下：
缺点：
【讨论】：
在网络表单中：
Viewstate 和 Postbacks 都存在很多问题，并增加了 Web 应用程序开发的复杂性。许多网页具有数百 KB 大小的 Viewstate，有时会影响应用程序的性能。
开发人员无法控制 Web 表单的呈现 HTML，以及呈现具有混合内联样式和不符合标准的已弃用标签的 html 的服务器控件。
Web 窗体的页面生命周期过于复杂，并且在 ASP.net 框架中的所有事物之间紧密耦合，并且使用单个类来显示输出和处理用户输入。
单元测试几乎是一项不可能完成的任务。今天，单元测试在现代软件开发中非常重要，尤其是当我们遵循敏捷方法和实践时。由于 web 是一个无状态的东西，Events、Postbacks 和 Viewstate 不是一个好方法。
使用 asp.net MVC 所有这些都简化了
如果这些事情不适用于您并且您喜欢使用网络表单，那么请坚持您最擅长的事情。 不要试图修复没有损坏的东西。
【讨论】：
不是我。 MVC 在简历中非常酷，但对于我们的客户（那些为我们的工作付费的人）来说，它并不是一个炫耀的东西。
他们通常需要正确、快速和安全的应用程序。就这样。他们不会想在三年内改变第三层的客户端部分！三年后，他们将改变一切，或完全改变。
层对于架构和编码来说很有趣，但它们的创建和维护成本很高，而且它们与我们的客户无关。 MVC 很酷，但真的没用而且很昂贵。
当然，除非您正在为 4 个操作系统和 3 个平台开发应用程序……但您将成为少数。
:o)
【讨论】：
WebForms 工作正常，如果您喜欢它们，请继续使用它们。
在我看来，MVC 模型的三大优势是：
ViewState 消失了，这可能会在网络上产生相当大的流量。 URL 可以重新映射为现在风靡一时的含义。 脚手架。我不知道，我个人认为这是撒旦并鼓励糟糕的编程习惯，但其他人似乎认为这是一个美丽的想法。
它还通过强制执行模型-视图-控制器模式来鼓励业务逻辑和表示之间的适当分离，但是好的 WebForm 代码大多也可以做到这一点。
所以，真的，如果您对 WebForms 的开销感到满意，并且可以接受丑陋的 URL 并且不想要脚手架，那么请坚持使用 WebForms。
编辑：哦，我确实错过了“干净”网址的一大优势。 MVC 应用程序对 SEO 更友好。它还可以让您更好地控制 HTML，但坦率地说，我不认为这是向前迈出的一大步。
【讨论】：