什么时候比MVC更喜欢ASP.NET WebForms

我知道微软已经说过

ASP.NET MVC不能替代WebForms。

一些开发人员说，WebForms的开发速度比MVC快。但是我相信编码速度会下降到该技术的舒适水平，因此我不希望有任何答案。

鉴于ASP.NET MVC为开发人员提供了对其应用程序的更多控制权，为什么不认为WebForms已过时？或者，什么时候我应该在新开发中比MVC更喜欢WebForms？

Webforms与MVC似乎现在是一个热门话题。我认识的每个人都宣称MVC是下一个伟大的事物。从我的细微摸索来看，这似乎还可以，但是不，我不认为这将是网络表单的终结。

我的推理，以及为什么要通过MVC选择Web表单的推理，更多是与业务角度有关，而不是一个比另一个更好。

时间/金钱是为什么在MVC上选择Web表单的最大原因。

如果您的大多数团队都知道Web表单，而您又没有时间在MVC上加快其速度，那么将要产生的代码可能不是高质量的。学习MVC的基础知识，然后跳入并完成您需要做的那个复杂页面是非常不同的事情。学习曲线很高，因此您需要将其纳入预算。

如果您有一个全部以Web表单编写的大型网站，则您可能更倾向于在Web表单中创建任何新页面，以便您的站点中没有两种截然不同的页面类型。

我并不是说这是一种全有或全无的方法，但是如果两者分开的话，它的确会使您的代码难以维护，尤其是如果并非团队中的每个人都熟悉MVC时。

我公司最近在MVC上做了三个测试页。我们坐下来设计了它们。我们遇到的一个问题是，我们的大多数屏幕在同一页面上都具有“查看”和“编辑”功能。我们最终在页面上需要多个表格。没什么大不了的，除非我们不使用母版页。我们必须对此进行修改，以便Webforms页面和MVC页面都可以使用同一母版页来获得共同的外观。现在我们有了一个额外的嵌套层。

我们需要为这些页面创建一个全新的文件夹结构，以便遵循正确的MVC分隔。

我觉得3页文件太多，但这是我个人的看法。

我认为，如果您没有时间/金钱来投资更新站点以使用MVC，则可以选择使用Webform而不是MVC。如果您对此采取半烦恼的方法，那将不会比您现在拥有的Web表单更好。更糟糕的是，如果技术混乱，您甚至可能会为公司中的故障设置技术，因为高层管理人员可能认为它不如他们所知。

我开发ASP .Net WebForms应用程序已经3年了，经过一天的MVC指导，我被卖了。MVC几乎总是更好的解决方案。为什么？

• 页面生命周期更简单，更高效
• 除了html控件外，没有其他控件。您无需调试输出即可查看ASP.Net生成的内容。
• ViewModels具有强大的功能，并且消除了进行手动控件绑定的需要，并且消除了许多与绑定有关的错误。
• 一个页面上可以有多个表单。这是WebForms的一个严重限制。
• Web是无状态的，MVC更紧密地匹配Web的体系结构。Webforms通过引入ViewState来引入状态和您所遇到的错误。ViewState是自动的，并且在后台运行，因此它并不总是按照您希望的方式运行。
• 如今，Web应用程序需要使用Ajax。不再有完整的页面加载是不可接受的。MVC使用JQuery使ajax变得更好，更轻松，更高效。
• 因为页面上可以有多个表单，并且架构是由对url的调用驱动的，所以可以执行一些时髦的事情，例如ajax使用JQuery将不同的表单（例如编辑表单）加载到当前页面中。一旦意识到这可以做什么，就可以轻松地完成出色的工作。
• ASP .Net WebForms不仅是基于html的抽象，而且是一个极其复杂的抽象。有时，您会得到一个奇怪的错误，并且需要花费更长的时间才能解决。在许多情况下，您实际上可以看到它在做什么错，但是您无能为力。您最终会做出奇怪的解决方法。
• WebForms对于设计师而言并不是一项好的技术。设计师通常喜欢直接使用html。在MVC中是一种视图，在WebForms中是半天的工作。
• 随着Web平台的快速发展，WebForms不会跟上潮流。它不知道HTML5的新标记或功能，除非您获得（通常）昂贵的第三方控件或等待Microsoft发布更新，否则它仍将呈现相同的内容。
• WebForms中的控件在很多方面限制了您。在MVC中，您只需获取JQuery库并将其集成到模板中即可。

我知道随着WebForms的发展，上述某些问题已得到一定程度的解决，但这是我的原始经验。总而言之，除非项目已经在使用WebForms，否则我很难找到WebForms的业务案例。

我通过电子邮件发送斯科特·格思里，一个MVC专家在微软。也许是最有资格回答这个问题的人。他很友好地回答：

“不同的客户寻求不同的编程方法，很多人喜欢WebForms并认为它很棒。其他人则喜欢MVC并认为它很棒。这就是为什么我们在两者中都进行投资的原因。”

因此，对我来说这不是技术问题。如果您愿意的话，它更像是一个“软问题”。个人喜好之一。这与你们几个人所说的一致。

感谢所有的答案。

这是一个陈旧的问题，有很多答案，但是没有一个我希望列出的答案。

简短的答案是：

• 如果您打算使用现代编程约定和ASP.NET平台的业界公认模式正确构建Web应用程序，请使用ASP.NET MVC。不利的一面是，您将希望了解HTML和客户端资源（Javascript，CSS）的工作方式，以及逐渐掌握MVC编程思想的MVC编程思想，尽管学习曲线陡峭，但一旦掌握，就会突然结束。
• 如果您正在使用或想使用以GUI为中心的RAD（快速应用程序开发），则可以使用ASP.NET Web Forms进行拖放，以非常快速地对某些事物进行原型制作，例如，在内部连接的按钮/数据网格行为15分钟后，解决方案就不会受到开发人员的支持。或者，如果您具有GUI或Windows Forms开发的背景并且希望将知识转移到Web ，请使用ASP.NET Web Forms 。

但是要正确看待这个问题，您必须了解它们的历史。

对于那些使用Visual Basic 6 ActiveX控件，服务器上的VB6 DLL和ASP Classic来构建动态Web应用程序的人来说，ASP.NET Web Forms是Microsoft的答案。当时，使用这些Microsoft工具进行Web开发确实是一团糟。连同整个Microsoft的.NET Framework基本上可以追溯到如何在Windows堆栈上进行生产性业务编程的绘图板一样，ASP.NET Web Forms在当时是令人赞叹和美观的。

整个方法是为开发人员提供两全其美的功能，类似于Windows应用程序开发，但具有Internet服务的功能。这个想法是，就像使用VB6 / WinForms“窗体”（窗口）一样，网页也是一个窗体（就像窗口一样，请参见），并且可以在该窗体上拖放标签，文本框，数据网格，按钮和VB / WinForms GUI开发人员习惯的其他内容。

要使按钮执行某项操作，只需将其拖放到设计器中，然后在代码编辑器中双击即可，告诉表单该“单击”事件发生时该怎么做。这就是Windows GUI开发人员使用VB6的GUI工具和竞争工具创建软件的方式，只是现在代码正在服务器上执行！哇！

这是2002年的技术。作为RAD开发的基于Internet的GUI解决方案的答案，它令人惊叹且美观，它给杂乱无章的软件开发人员世界带来了力量感，这些软件开发人员具有他们需要实现的业务目标。

不幸的是，这种编程模型过多地强调了Windows GUI编程的隐喻，以至于它承担了必需的实现细节，为适应事件生命周期所必需的所有负担，并掩盖了简单HTML和HTML的丑陋细节。这些拖放组件和控件将输出的脚本。归根结底，支持真实应用程序的开发人员不可避免地必须深入研究这些组件或编写自己的组件，因此他们将与该基础结构进行战斗，这些战斗将一堆堆地堆着，拔掉头发，眼泪。

备份。洗你的手。让我们再次看一下业务问题。我们的业务目标是什么？

我们需要构建和管理Web应用程序。我们的限制是我们拥有位于HTTP，HTML，Javascript和CSS上的万维网，并且在服务器上我们具有业务规则，数据库和少数几种出色的编程语言（例如C＃）。我们真的需要这个Windows GUI隐喻来驱动我们的开发方法吗？为什么我们不能只关注应用程序问题并消除GUI隐喻？

这就是ASP.NET MVC出现的地方。它始于自称为“ Alt.Net”的开发人员的反叛，他们希望恢复正确和纯粹的软件开发原则。不再烦恼，只需专注于业务目标和软件最佳实践。

在这种情况下，这实际上是什么意思：

1. 关注点分离。例如，数据组件不需要知道如何呈现其数据，也不必在视图标记中添加数据库连接配置详细信息，这样开发人员就可以在编辑和编辑时集中精力关注他关注的领域。测试代码。
2. 对HTML和相关资源的实质性接触的暴露和全面支持。在Web窗体中，HTML被隐藏起来，不鼓励开发人员对此大惊小怪。在ASP.NET MVC中，鼓励开发人员管理这些细节。实际上这是必要的。这样做的好处是，开发人员可以重新学习欣赏HTML，CSS和脚本的简洁语义，并使用它而不是反对它。
3. 业务对象的可测试性。控制器和模型更适合于程序化单元测试，因此可以对实现进行验证以满足业务目标，并且可以对所做的更改进行验证以确保它们不会中断。使用Web Forms很难进行测试，因为不能将组件设计为不能单独进行测试，并且整个开发输出都围绕页面表单及其事件生命周期进行，而业务逻辑和表示逻辑则相互交织在一起。

请注意，HTML已经是一种非常高级的标记语言，而Javascript已经是一种高级编程语言。如果我们处理汇编语言和C语言，整个故事会有所不同。

因此，在＃2上进行扩展，ASP.NET MVC的另一个目标是使开发人员能够组织其解决方案的“视图”部分的前端详细信息，并利用行业其余部分所建立的丰富基础前端客户端平台。

您会发现ASP.NET MVC开发人员可以在不与服务器端体系结构抗衡的情况下使用丰富的Javascript库和客户端模板技术。最初，ASP.NET Web窗体不是这种情况，因为Web窗体根本不希望您查看HTML或脚本，除非您确实必须（在这种情况下，请当心，这并不是为了淡淡）心。

我已完全转换为ASP.NET MVC，并且没有回头，那表示我仍然必须维护几个非常大的WebForms应用程序。这是我的看法：

WebForms
当您对网格有一些沉重的负担时，请使用它们。当您有一个非常适合表格格式的简单数据集并且想要为用户提供一种更新记录的简单方法时，网格控件确实非常好。是的，我知道MVC 4确实具有令人眼花A乱的Ajax列表类型的东西，您可以使用它，效果很好，但是在我们的业务中，我们经常需要昨天运行一些东西，并且老式网格可以很好地工作，并且用户很乐意成为能够与欢乐合唱跨越网格。对我来说，这确实是WebForms最好的东西。但是，作为瑞安指出WebForms可能会造成很大的麻烦，因为您正在从一个漂亮的代码隐藏文件中播放文件。同时将所有控制器类型的内容与视图混合在一起可能既是玫瑰又是荆棘。

MVC
当您确实想自己滚动自己并有机会从头开始启动应用程序时使用此功能。拥有一个明确定义的MVC应用程序要花很多时间才能开始，但是其在可维护性方面的好处超过了初始设置成本。如果您想进行有趣的Ajax交互，更喜欢使用代码（例如干净的url和路由）编写模型，并且能够控制应用程序的整个流程，那么这绝对是可行的方法。一开始需要一些时间来适应，但我认为这是未开发应用程序的更好选择。

总之，对我而言，它可以归结为网格和网格。:)

我的经验：

• 编写CakePHP项目一年。
• 在六个月内完成了一个中型Webforms项目。
• 在Windows Forms项目上工作了三年。

在经历了这段经历之后，我尝试使用Webforms编写另一个应用程序，但是在为Webforms如何使开发人员免受开发他们正在使用html，javascript和css的现实的困扰而苦苦挣扎了一天之后，我感到沮丧。

然后，我尝试了MVC，并且对输出进行了更直接的控制（以及来自CakePHP的MVC范例的一些经验），我能够完全按照我每天所需的方式完成这个简单的应用程序，大约需要1/2天。

像jQuery这样的强大UI框架的可用性极大地消除了放弃直接控制输出的吸引力，而倾向于使用通常笨重的预构建UI组件。

我更喜欢webforms，因为我的背景是Windows开发。

开发速度是一个关键问题，我可以很容易地将一个问题传递给印度某人，以便在一夜之间用表格进行修复，而且，如果我在页面上遇到速度问题，那么一本关于asp.net速度的非常好的书很方便（Rick Kiessig是那个人）。

webforms适用于ex Windows人mvc适用于web人

但是，在现代世界中，里克（Rick）写了一本很棒的书，服务器在印度每天的速度在不断提高，而廉价的编码器在不断增长，嗯，webforms具有优势

如果有选择，我的2美分是始终将ASP.NET MVC用于新项目。我认为，Webforms并不是开发Web应用程序的好方法。

我认为抽象化基本REST是不好的，整个回发模型是不好的，依赖于GUI编辑器处理html / css的方式是不好的，对像向导和GUI这样的东西进行设置的重视是不好的，URL不好

我已经阅读了所有答案，并认为我的个人经历会为上述答案增加一些帮助。

3-4年前，我使用Webforms开发了2-3个网站项目。大约在那个时候，MVC不在或我没有听说过。对我来说，开发自然而然（我来自Win-forms开发，之前没有Web开发经验）对我来说是快速的，因为我不需要学习HTML的详细信息，并且Web控件也帮了很多忙（地狱，这使生活更轻松） 。

现在，经过所有这些时间，直到最近我才开始从事任何Web项目，而只是使用WPF构建一些Windows应用程序。

几天前，我有了一个网站的构想并打算开发它：这次是在MVC中进行（因为它无处不在，而且我需要学习任何一种，所以我选择了MVC）。该项目仍处于开发阶段，因为我仍在学习和共同建设。

所以，我发现两者之间的主要区别是：

• 对于Windows开发人员来说，Web表单将永远是有利的。Windows开发人员的Asp.net学习曲线有点陡峭

• 对于使用其他技术进行Web开发的人来说，MVC将受到青睐，因为它可以模拟所有最新技术。

• 如果您具备HTML和CSS的丰富知识，则在MVC中进行开发会更轻松，更干净。

• 部署仍然是一个问题。在Web表单中，只需复制和粘贴即可。但是，这需要做一些事情。

简而言之，他们两个都会在这里待一会儿。

我尚未看到此线程的现有15个答案中提出的考虑因素，但我认为值得考虑。

根据我的经验，Web窗体比MVC更类似于Win Forms和WPF。鉴于此，我认为当团队在此类技术方面拥有最丰富的经验时，或者当Web Forms项目将接口与现有（或同时开发的）Win Forms或相同的数据集提供接口时，我可能会考虑选择Web Forms。 WPF项目。这样做使开发人员可以更轻松地跨项目，因为两者之间的应用程序逻辑可能非常相似。

正如其他答案所指出的那样，MVC框架的开发与Ruby，PHP，Python等的Web开发相比，更像是Microsoft的Web开发。因此，MVC的选择自然会受到团队在这些领域的经验以及其他答案中提出的因素的影响。

几年前我们不使用MVC的原因是它是Microsoft的一项不成熟技术。在过去的几年中，我们现在使用的是更成熟的版本（4），MS似乎已经确定了解决方案。但是，我们仍然不愿意使用MVC开发主要的LOB应用程序，因为我们要在版本4中使用的功能需要Windows 2012服务器（通过IIS8的Web套接字）。我估计在1年后，我们将更加接受MVC，因为希望有更多的第三方控件可用，技术已经解决，我们将拥有支持它的基础结构。

该决定取决于您的偏好，要求，甚至取决于您的知识和经验。

培训学习MVC的时间或获得交付的时间。所有这些事情很重要，选择一个或其他方式。

难道不是一个人胜于另一个人，仅仅是方法或框架都有优点和缺点。

我非常喜欢MVC 3，我建议您尝试一下自己的经验，但是我要说的是，MVC中的程序是一种干净，有趣，灵活，可扩展，安全和结构化的方式。

问候，

我之所以选择WebForms而不是MVC的唯一原因是，与MVC相比，您拥有更多的WebForms第三方UI控件。我之所以选择MVC，是因为我在WebForms上工作过多，并且想使用新的/新的东西，但仍然来自MS shop ：）

基本上，没有什么可以阻止您关闭WebForms中的视图状态并使用ViewModels和if / for循环，而不是模型绑定和服务器端控件。

这是WebForms还是MVC代码：

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

我在WebForms中发现的唯一限制是，如果使用依赖注入/控制反转，则由于WebForms页面必须具有无参数构造函数，因此无法进行构造函数注入，因此必须使用属性注入。这真的有什么大不了的吗？

ASP.NET MVC确实是Ruby的一种解决方案，它是一种新的，新潮的（IMO）更好的方法，可以将浏览器（客户端）与服务器尽可能地分离。

ASP.NET Webforms使您可以从服务器端对客户端进行很多控制，并可以直接访问几乎所有内容。本质上，您的视图和控制器是同一个视图，这给了您很多功能，并且在大多数情况下还很混乱。

ASP.NET MVC通过分离.aspx文件和.aspx.cs文件的紧密耦合来分离视图和控制器，而.aspx文件和.aspx.cs文件在Web窗体中是紧密耦合的。

本质上，区别在于您需要进行更多（通常是所有）处理以将数据显示到视图文件中，并将业务逻辑和其余部分留在控制器中，从而使它们既按惯例保持整洁，又较少访问每个逻辑除了网络表单所允许的。

在我看来，它们具有足够的相关性，并且具有与应优先考虑的功能大致相同的功能。

出色的WebForms开发人员可以生产与强大的MVC开发人员同样强大的产品。但是，试图强迫自己采用MVC的伟大的WebForms开发人员将会失败。出色的MVC开发人员尝试WebForms也是如此。

它们不是完全独立的实体，并且只要Microsoft继续支持这两个实体，我相信您将继续看到每个杰出的开发人员混杂在一起的群体。

假设我们都精通所使用的技术，那么所有这些都是关于个人选择的。我使用WebForms设计方法已经很多年了，我必须说，唯一的缺点是由于它的方法过于简单，许多人没有花时间去挖掘它的强大功能。

我最近使用MVC完成了一个项目，尽管我非常喜欢应用程序开发的设计方法（可以为您提供更多控制权，干净的url，SOC等），但实际上它提供了很多，而WebForms却没有。实际上，jQuery的出现及其与WebForms（以及MVC）的配合使这些争论不再是问题。当人们谈论关注点分离是MVC相对于MVP的优势时，我问他们对面向对象编程的了解程度如何，以及他们使用了抽象和多态原理的程度。

我目前对使用这两种技术都很满意，我会根据情况进行选择。坦白地说，这取决于您，但事实是，并非每个人都花时间深入学习特定技术的功能。

遇到编程问题时，我经常在网上寻找答案。Webforms具有大量的信息/组件，可以执行几乎所有操作。在MVC中，由于在线资源较少，而使某项工作所需的抽象层限制了我曾经可以做的事情。MVC完全损害了我作为开发人员的工作效率，而使用Webforms却没有。因此，到目前为止，我坚持使用Web表单，直到MVC成熟到可以替代它为止。

好吧，WebForms有更多可用的学习资源（这是由于它较旧），因此，那些“不了解”的新程序员将更有可能找到有关该较旧技术的信息，而不是像MVC这样的较新事物。 。

高级/有经验的程序员年龄更大，并且由于他们使用的技术比在新技术中编程的时间更长，因此他们将更熟练地使用旧技术。

除非您能花费金钱和精力使您的家伙像在WebForms应用程序中一样精通MVC，否则，您无疑将尝试尽可能长时间地推迟升级到新平台。

因此，这就带来了几个后勤问题：就降低质量和缩短部署时间而言，MVC的好处是否超过了成本？如果我有一个完全用WebForms编写的网站，将MVC集成到其中是否值得付出努力和金钱？

如前一个评论者所述，MVC还可防止您实现与WebForms相同的与控制器的接口级别。尽管我全力以赴，以“保持用户充实/学习知识”的一面，但对于团队而言，部署/实现一个程序时，仍然会不合理地麻烦，该程序对于他们编写的所有内容均严格遵循该范例。

我认为这两种技术之间的差距并不像以前那样大。

• Web表单可以使用MVC使用的路由引擎（或类似的东西）。
• 脚本管理器可以组合脚本，从CDN加载，甚至延迟脚本的加载。

为了直接回答您的问题，我认为这取决于偏好和/或项目是什么。他们俩都采取了截然不同的发展方式。我个人一直在努力迈向MVC，但仍然喜欢使用Webforms。我认为应该使用MVC或Webforms的答案是您通过体验这两种技术来决定。