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

#1 楼

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

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

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

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

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

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

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

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

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

#2 楼

我开发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将不同的表单（例如编辑表单）加载到当前页面中。一旦意识到这一点，就可以轻松地完成令人惊奇的事情。有时，您会得到一个奇怪的错误，并且需要花费更长的时间才能解决。在许多情况下，您实际上可以看到它在做什么错，但是您无能为力。您最终会做出怪异的变通办法。
WebForms对于设计师而言并不是一种好的技术。设计师通常喜欢直接使用html。在MVC中是一种视图，在WebForms中是半天的工作。
随着Web平台的快速发展，WebForms不会跟上潮流。它不知道HTML5的新标记或功能，除非您获得（通常）昂贵的第三方控件或等待Microsoft发布更新，否则它仍将呈现相同的内容。
WebForms中的控件在很多方面限制了您。在MVC中，您只需获取JQuery库并将其集成到模板中即可。

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

#3 楼

我通过电子邮件发送了Microsoft MVC专家Scott Guthrie。也许是最有资格回答这个问题的人。他很友好地回答：


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


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

感谢所有的回答。

#4 楼

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

简短的答案是：


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

但是要正确看待这一点，您必须了解每个人的历史。ASP.NETWeb窗体是Microsoft对那些使用Visual Basic 6 ActiveX控件，服务器上的VB6 DLL和ASP Classic构建动态Web应用程序的人的回答。当时，使用这些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和脚本的丑陋细节。归根结底，支持真实应用程序的开发人员不可避免地必须深入研究这些组件或编写自己的组件，因此他们将与该基础架构进行战斗，这些战斗将一堆堆地堆着，扯掉了头发，眼泪。

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

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

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

在这种情况下，这真正的意思是：



关注点分离。例如，数据组件不需要知道如何呈现其数据，也不必为视图标记添加数据库连接配置详细信息，这样开发人员就可以在编辑和编辑时集中精力关注他关注的领域。测试代码。

暴露和全面支持暴露于HTML和相关资源的本质。在Web窗体中，HTML被隐藏起来，不鼓励开发人员对此大惊小怪。在ASP.NET MVC中，鼓励开发人员管理这些细节。实际上这是必须的。这样做的好处是，开发人员可以重新学习欣赏HTML，CSS和脚本的清晰语义，并使用它而不是反对它。

业务对象的可测试性。控制器和模型更适合于程序化单元测试，因此可以对实现进行验证以满足业务目标，并且可以对所做的更改进行验证以确保它们不会中断。使用Web Forms很难进行测试，因为不能将组件设计为不能单独进行测试，并且整个开发输出都围绕页面表单及其事件生命周期进行，而业务逻辑和表示逻辑则交织在一起。请注意，HTML已经是一种非常高级的标记语言，而Javascript已经是一种高级编程语言。如果我们要处理汇编语言和C，整个故事将有所不同。

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

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

#5 楼

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

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

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

#6 楼

我的经验：

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

在经历之后，我尝试使用webforms编写另一个应用程序，并且在webforms如何试图使开发人员免受开发他们使用html的现实的困扰之后，我感到沮丧，javascript和css。

然后我尝试了MVC，并且对输出进行了更直接的控制（以及来自CakePHP的MVC范例的一些经验），我能够完全按照我的方式来完成该简单应用程序希望在一天的1/2天内得到它。 。

#7 楼

我更喜欢webforms，因为我的背景是Windows开发。在网页上发布的一本关于asp.net速度的非常好的书非常方便（Rick Kiessig是该书的作者）。 >
，但是在现代世界中，里克（Rick）写了一本很棒的书，服务器每天都在增加速度，而印度的廉价编码器越来越好，Webforms具有优势。

#8 楼

如果有选择，我的2美分是始终将ASP.NET MVC用于新项目。在我看来，Webforms并不是开发Web应用程序的好方法，
对GUI编辑器的依赖不好，对诸如向导和GUI这样的东西进行设置的重视很差，URL不好。

#9 楼

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

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表单中，只需复制和粘贴即可。但是，这需要做一些事情。

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

#10 楼

我尚未看到此线程的现有15个答案中提出的考虑因素，但我认为值得考虑。 。鉴于此，我认为当团队在此类技术方面拥有最丰富的经验时，或者当Web Forms项目将接口提供给与现有（或同时开发的）Win Forms相同的数据集时，我可能会考虑选择Web Forms。 WPF项目。这样做使开发人员可以更轻松地在项目之间进行交叉，因为两者之间的应用程序逻辑可能非常相似。 ，PHP，Python等比其Microsoft同类产品；因此，MVC的选择自然会受到团队在这些领域的经验以及其他答案中提交的因素的影响。

#11 楼

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

#12 楼

这个决定取决于您的喜好，需求或什至您的知识和经验。

培训MVC的学习时间或交付时间。所有这一切都关系到选择一个或其他方法。

不是一个方法要比另一个方法好，仅仅是方法或框架都有优缺点。 3，我建议您尝试一下自己的经验，但是我要说的是，MVC中的程序是一种干净，有趣，灵活，可扩展，安全和结构化的方式。 >

#13 楼

我之所以选择WebForms而不是MVC的唯一原因是，与MVC相比，您拥有更多的WebForms第三方UI控件。我之所以选择MVC，是因为我在WebForms上使用了太多的东西，并且想使用一些新鲜的东西，但仍然来自MS shop ：） ViewModels和if / for循环，而不是模型绑定和服务器端控件。

这是WebForms还是MVC代码：

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

我在WebForms中发现的唯一限制是，如果使用依赖注入/控制反转，您不能使用构造函数注入，因为WebForms页面必须具有无参数构造函数，因此您必须使用属性注入。这真的有大事吗？

#14 楼

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

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

本质上，区别在于，您需要进行更多（通常是全部）处理以将数据显示到视图文件中，将业务逻辑和其余逻辑留在控制器中，以使其按照惯例保持整洁，而且彼此之间的访问比Webforms允许的少。

#15 楼

在我看来，它们具有足够的相关性，并且具有应优先考虑的大致相同的功能。但是，试图强迫自己采用MVC的伟大的WebForms开发人员将会失败。出色的MVC开发人员也可以尝试使用WebForms。

它们不是完全独立的实体，只要Microsoft继续支持这两个实体，我相信您会继续看到各有不同的杰出开发人员群体。

#16 楼

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

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

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

#17 楼

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

#18 楼

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

资深/经验丰富的程序员相对较老，并且由于他们对新技术的编程时间比对新技术的编程时间长，因此他们将更加熟练于较旧的技术。

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

因此，它带来了几个后勤问题：就降低质量和缩短部署时间而言，MVC的好处是否超过了成本？如果我有一个完全用WebForms编写的网站，那么将MVC集成到该网站中是否值得付出努力和金钱？使用控制器，就像使用WebForms一样。尽管我全力以赴，以“防止用户充斥/学习”事物，但是对于团队来说，部署/实现一个程序对于他们编写的所有内容都严格遵循该范例仍然是不合理的麻烦。 >

#19 楼

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


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

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