关于 ASP.NET MVC 的常见问题之一是为什么要在 ASP.NET Web 窗体上使用它？答案通常包括 ViewState 和干净的 URL 等。最后，您会发现有关使用正确工具完成工作以及它们用于不同目的的宣传。但是，我不相信我曾经见过这些目的是什么。那么，你什么时候会真正选择 ASP.NET MVC 而不是 ASP.NET Web 窗体，还是 ASP.NET Web 窗体而不是 ASP.NET MVC？
【问题讨论】：
标签： asp.net asp.net-mvc webforms
您不要选择 ASP.Net MVC 而不是 ASP.Net，因为 ASP.Net MVC 仍然是 ASP.Net。您确实选择了 ASP.Net MVC 或 ASP.Net Web 表单，这样做有很多充分的理由：
另一方面，Web 表单确实有一些优势：
结果是，如果您在公司 LAN 环境中构建业务应用程序（老实说，这仍然是大多数 Web 开发人员），Web Forms 真的很棒。从这个意义上说，微软确实了解他们的市场。但是，如果您正在为公共 Internet 构建应用程序，您可能需要 MVC，这样您就可以进行彻底的测试并确保您的页面不会因不必要的 ViewState 或 JavaScript 数据而臃肿。
此外，过去几年发生的变化是，即使是许多企业 Intranet 应用程序现在也需要支持家庭/远程使用，这使得 MVC 对这些人群的吸引力比以往任何时候都更大。
【讨论】：
如果您的所有团队成员都足够熟练地管理“对 HTML 的控制”，请使用 MVC，否则您的代码将变成 tag soup。
换句话说
bool useMvc = true;
foreach (TeamMember member in team.Members)
{
useMvc = useMvc && member.IsSkilled;
}
【讨论】：
【讨论】：
我会给你几个目的，有明显的优势。
如果您的目标是面向公众的网站，该网站将依靠流量，请使用 MVC。它是搜索引擎优化的最佳选择。
如果您的目标是像桌面应用程序一样运行的企业 Web 应用程序，我会倾向于使用 Web 表单，因为如果使用得当，状态管理和将资源划分到底层服务器控件中会提供巨大的优势。
【讨论】：
开发人员面临的最大问题是管理复杂性和保持代码“干净”。 MVC 为开发人员提供了利用 OOP 来降低复杂性并使代码易于阅读的控制权。
网络表单在短期内发展得更快，但在维护和增长方面不利于长期可持续性。
【讨论】：
我使用 Web 表单已有 13 年，使用 MVC 已有 2 年了，当我开始使用 MVC 时，我也有类似的问题。这是我的收获。
话虽这么说：
我发现，一旦掌握了 MVC，处理基本表单和任何类型的简单“模型”（也就是具有非常简单、直接的关系集的表）就更容易了例如具有链接到用户、产品等的表的订单。一旦您开始陷入一些更复杂的关系并需要返回大量条件结果集、依赖参数、具有复杂的存储过程……那么 Web 表单就是处理这个要好得多。如果您不必处理这种级别的复杂性，MVC 可以让开发变得更快，尤其是在处理您已经拥有数据库的方法时，因为它已经为您创建了如此多的代码和验证
如果您对数据库设计不是很有经验，MVC 可以为您完成这项工作。它可以真正为您构建数据库。
MVC 没有很多 Web 窗体具有的内置控件（Gridview、FormView、站点地图、分页列表）。一切都必须从头开始编写，但幸运的是，很多人已经在 NuGet 中为您发明了这些东西，您可以将其下载到您的项目中
MVC 在很大程度上依赖于 URL 的结构。路径、查询字符串等。如果您发现您的应用程序需要执行大量表单 POST 而不是 GET-ting，您将不得不进行大量调整或 AJAX 发布。如果您有一个无法更改的固定 URL，那可能会很痛苦。这是可行的，但只是有点小技巧（或者你可以只使用 Angular）。
MVC 没有视图状态。如果您需要从一个帖子到另一个帖子隐藏变量并将它们持久化，这有点困难。 MVC 确实有 ViewBag 之类的东西，它可以让您将数据从控制器传递到您的页面，但它会在页面呈现后清除。还有一种叫做“Tempdata”的东西，它的作用类似于会话状态，但更临时。但是，它依赖于会话状态，这不是持久数据的理想方式。会话变量和临时数据变量适用于用户级数据（登录者的个人资料信息），但同一用户打开两个不同的选项卡可能会导致这些会话/临时数据变量在处理时相互覆盖实际模型数据。
如果您正处于十字路口，我会选择 MVC。 MS 正在推动它，对 Web 表单的支持可能会开始消失
【讨论】：