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