您为什么要通过Web表单使用MVC？

Question

最近，一位建筑师将我们公司描述为提供劳斯莱斯解决方案（MVC），而他所需要的只是丰田（Web Forms）。

我很想知道您对Web表单与MVC作为建筑选择的看法。

Answer 1

劳斯莱斯/丰田的类比是极其缺陷和误导的。一个（ASP.NET MVC）不仅是另一个更典型或更昂贵的版本（ASP.NET WebForms）。它们是使用ASP.NET构建Web应用程序的方法截然不同的方法。

对我来说，MVC和WebForms之间的最大架构差异是它们如何与网络无状态环境一起工作：WebForms努力构建一组抽象，以隐藏Web编程的无状态性质，而MVC涵盖了无状态环境并与之一起工作它。

每种方法都有其好处和损害，但是我真的很喜欢使用MVC建立网站的感觉更多 自然 比WebForms（及其 漏水层的一层).

Answer 2

旧问题，但值得一个更详细的答案，以防万一其他人实际上仍然存在困境。

最终，WebForms是一种薄的解决方案，这意味着您按下一堆漂亮的按钮，并为您构建了前端（客户端）东西。如果您有知道如何在WebForms中驱动它的人，并且绝对没有可维护性/可修改性问题，并且该站点是完全短期且可支配的，那么这种方法根本没有错。可以学习如何做自己的事情，但是在这种情况下，它需要知道Web Forms都试图保护.NET应用程序开发人员以及所有使大多数客户端Web Devs都想谋杀Microsoft的Web Forms的东西。负责工程师。

在99.5％的其他用例场景中，我们已经停止尝试从应用程序开发人员隐藏网络，因为实际上，如果您想编写Web应用程序，您会更好地了解Web的工作方式。具有讽刺意味的vs薄客户解决方案的讽刺是，不可避免地，稀薄的客户方法不可避免地会使垃圾从您的前端膨胀，这绝非表现。更重要的是，这些解决方案总是使事情变得不灵活，因为那些实际知道自己在做什么并且不想受到实际框架的人的地狱。

没有什么比让某人了解CSS，JavaScript，HTML，XHR的一切那么毫无意义的，并通过将它们的每一步都用一个框架来使它们完全毫无用处。

• 清除头部标签中的所有“不需要”脚本标签，以防止您拧紧脚本依赖项。 （最好让“脚本经理”为您处理）。

• 坚持您将所有HTML包裹在一个巨大的形式标签中。 HTML不允许在表单内部表单，因此您可以形成WebForms的方式或根本没有办法。

• 通过与浏览器进行交互以将消息发送给服务器，然后在服务器响应时做出反应，从而创建像18步的“生命周期”，以归结为对UI事件的反应。用一大堆巨大的垃圾来抽象这一过程（公平地说，MS并不是唯一一个试图这样做的公式）。

• 实际上，竭尽所能，以妨碍对问题使用非电视解决方案。示例：当我是一个更少年客户端的开发人员时，我花了一整天的时间找到了在页面顶部制作提交按钮的方法巨型的东西）。通常这需要5分钟，但是经过几个小时的反向工程，WebForms JavaScript负责，我发现它们是设置我在当时不知道的属性的其他事物，告诉您最后的表单要元素是什么重点是，当单击提交按钮时，仅Microsoft官方提交（TM）按钮就可以在激活Microsoft官方提交（TM）处理程序的情况下使用。

因此，不，劳斯莱斯vs丰田是完全不合理的。我会说的，这是一个非常合理的现代汽车，您为与Microsoft工程的Pinto付出了太多，并带有板载系统，当它发现您从微软以外的人那里购买了汽油或油时，它会自动使90度转弯，并检测到它方便的墙壁猛击。对于自杀品牌的驾驶员来说，这是一个理想的汽车，他对网络一无所知，并希望发誓对微软的终身忠诚。

所有.NET MVC的确是简单而合理的，并且不会重新发明自己的层来拍打在网络顶部。它只是与那里的东西一起工作，可以帮助您淘汰一些样板。有更好的/更便宜/更便宜的/自由式框架可用，但是如果您已经将自己锁定在.NET中，那么您可能会做得更糟。

但是说真的，请遵守！@＃$远离WebForms。现在几乎死了。放手吧。告诉您的客户，如果他们也向您保证您的独家且有利可图的小时支持合同，则您将以三倍的收入来做这件事不愿意继续将10,000行Ajax.js文件的庞然大物添加到他们无法触摸它的dll屁股中。

Answer 3

ASP.NET MVC解决方案不必比WebForms解决方案更复杂。就我个人而言，我发现ASP.NET MVC实际上比WebForms要简单得多，而且它似乎本质上更清洁。

根据我的经验，许多MVC框架（ASP.NET，Rails，Codeigniter等）都具有相同的核心功能和约定。从网络角度来看，Webforms确实是奇怪的鸭子。我的猜测是，大多数Web程序员在拾取ASP.NET MVC方面的速度要比WebForms快得多。

Answer 4

您将在ASP.NET WebForms上使用ASP.NET MVC的主要原因是可检验性。当然，您可以使用单元测试Webforms，但这需要嘲笑框架和很多痛苦。第二个原因是MVC确实使它有点 更轻松 分开关注。这可以提供大量的代码重复使用，并使您的代码松散耦合。这并不意味着不可能在ASP.NET中使用MVP之类的模式进行相同的操作。

MVC的缺点是，您失去了很多功能，并且在过去十年（几乎）中已内置在Webforms中。 MVC自成立以来提供了相似功能以来，已经走了很长一段路。

就性能而言，是否有人可以以一种或另一种方式证明哪种技术“更快”？

我认为一个人没有比另一个更好。我确实非常喜欢MVC框架，并成功地使用了它，但是我始终确保选择与项目相匹配的技术。