我们讨厌经典 asp 但今天仍然存在于 web 表单中的东西答案

【问题标题】：Things that we hated about classic asp but still exist in webforms today我们讨厌经典 asp 但今天仍然存在于 web 表单中的东西
【发布时间】：2010-12-01 10:04:43
【问题描述】：

我正在研究我的团队从 webforms 迁移到 MVC 的原因列表，我认为一个很好的起点是展示“为什么我们应该迁移”与一组经典的 asp 和 webforms 中的东西常见的。

如：

Spagetti 代码（违反 SRP）

经典 ASP - 每个 .asp 文件都感觉像一个大泥球
网络表单 - 这个大泥球从视图变成了臭名昭著的“代码隐藏”

请记住，我的开发人员不是那种在不被推送的情况下实现 MVP 之类的东西的类型，这也是我喜欢 MVC 的部分原因（尽管保持控制器精简是一种学习经验）

更新我知道你可以在任何平台上用任何语言制造混乱。我也知道 MVC 不会解决这个问题。我也知道需要进行一些真正的指导才能让团队写得一团糟，以了解为什么这很难维护。但我觉得这个机会可以让我表达对 SOC/责任驱动设计/可测试性/等的需求。

关于使用 webforms 编写更易于维护的软件：根据我的经验，在 webforms 中实现像 MVP 这样的表示模式以尊重 SRP/增加可维护性/启用单元测试等比使用开箱即用的 MVC 要做的工作要多得多（你会得到结果相同）。它是否有效 - 是的，我过去曾通过这种方法取得成功。但是，如果我可以利用一种更自然的方法来进行平台中的 Web 开发，我会的。

我一直在找人指出普通 9 到 5 岁的开发人员在编写经典 asp 时“希望”摆脱的东西，但在他们进入网络表单后却从未遵循过。（再次强调，与我共事的大多数开发人员只是简单地将他们在经典 asp 中抱怨的烂摊子转移到后面的代码中，并“认为”这是朝着正确方向迈出的一步）。

【问题讨论】：

"...与我一起工作的大多数开发人员只是简单地将他们在经典 asp 中抱怨的烂摊子转移到后面的代码中，并“认为”这是朝着正确方向迈出的一步.. 。“ ...当心！您正在描述（大部分）SharePoint 2007！希望2010年会更好！

标签： asp.net asp.net-mvc asp-classic webforms

【解决方案1】：

部分问题在于，您可以轻松地拥有“Spaghetti Code”和“大泥球”以及编写糟糕的 MVC 视图 - 如果您说这将是一种“学习体验”，让您的控制器保持精简，那么您'将很难保持视图干净整洁。

另请参阅StackOverflow.com Search for "WebForms vs MVC"，了解您正在寻找的论据类型的其他类似问题。

根据问题的编辑进行编辑

好的，我不喜欢 ASP.NET 中已被 ASP.NET MVC 删除/解决的东西：

必须记住设置 ViewStateEnabled = false 以减小我的页面大小。
对控件的客户端 ID 几乎没有控制（这将在 ASP.NET 4.0 中解决，但您可以在其中设置 ClientID）。
对控件呈现的 HTML 几乎没有控制（尽管这可以通过 CSS 控件适配器来缓解，它将内置在 ASP.NET 4.0 中，并且是我认为的默认行为）。

这些是我在构建基于 MVC 的网站时真正欣赏的主要内容。

【讨论】：

【解决方案2】：

老实说，您正在寻找错误的转换理由。迁移到 ASP.NET MVC 并不能解决任何这些问题。仍然有可能拥有与经典 ASP 或 Webforms 一样多（甚至更多）的意大利面条代码（或泥球）的巨大视图。

您的谈话要点应该更多地关注关注点的分离、友好的 URL（在 Web 表单中也可用）、对页面的更多控制等。

您也可以查看 Microsoft 的这篇博文：

Web Forms vs. ASP.NET MVC

...记下页面底部的短语。

ASP.NET MVC 不是反Web Forms

它们都有各自的用途。由于编码不佳而从另一个切换到另一个不会有帮助。你可以在任何一个中做到这一点......

【讨论】：

【解决方案3】：

ASP.NET/webforms 似乎（借用自 Joel Spolsky）在一个基本上无状态的介质上的状态的“大泄漏抽象”。虽然这（有人告诉我）对于 WinForms 开发人员进入 Web 开发非常有用，但由于这个原因，在我看来，“Web 表单”一直是一个存在根本缺陷的范例。

当我（最近）开始学习 Web 开发（来自桌面背景）时，我是通过 Python/Django 和 RoR 了解它的，但我并没有真正接触过“经典”的 ASP.NET、webforms ，或 J2EE。我想在我的天真中，我猜我只是假设所有的 Web 开发（或至少所有的大型 Web 开发）都是基于 MVC 模式的，它似乎非常适合 Web。在野外遇到“经典” ASP.NET 已经..令人大开眼界o_O

假设您在这件事上有任何选择，为什么您不想要使用 ASP.NET MVC？

【讨论】：

没有“经典 ASP.NET”。当人们谈论“经典 ASP”时，他们谈论的是 ASP.NET 的 VBScript/Jscript 前身，它被简单地称为 ASP 并且是完全不同的野兽（解释，没有 CLR 等）。当然，“经典 ASP”也不是正式的产品名称——只是一个流行的术语，用于避免与 ASP.NET 混淆。
另外，是的，是的，是的，是的，对 ASP.NET 来说是一个“大泄漏抽象”。

【解决方案4】：

与我一起工作的大多数开发人员只是把事情搞砸了他们在经典的 asp 中抱怨并将其移至背后的代码并“认为”这是正确的一步方向）。

嗯，它是朝着正确方向迈出的一步——总比没有分离好。不过，是的，它仍然经常是一大团泥巴。

在我乐观的时候，我认为这很好，也许它只是将球泥转移到代码隐藏中，但也许它种下了“嗯，也许内容应该与演示分开！”的种子在一些人心目中。 MVC 或类似的模型当然是他们最终到达的目的地。

（不要问我在我不乐观的时候是怎么想的……哈哈。）

【讨论】：

【解决方案5】：

我想提醒您，您报告的核心问题不是技术问题。对于您描述的那种开发人员（没有动力、教育不足或能力不足），我建议您可以考虑不要迁移到 asp.net MVC 框架。

MVC 框架无法解决在工作中学习和利用良好设计原则的团队的问题。但是当前形式的 MVC 框架将为他们的板块添加额外学习的 LOI。 MVC 框架并没有太多 RAD 特性的方式，正确使用它需要对 Http 本身的本质有深刻的理解。

一个糟糕的 MVC 应用程序将比一个糟糕的 webforms 应用程序更糟糕。使用 webforms，您可以通过对 Http 等更深层次的交互了解不多，因为框架本身处理大部分状态管理。

对于像你描述的程序员这样的程序员，你可能最终会尝试教他们如何进行 OO 设计，同时你也尝试教他们 Http 的内部结构并让他们学习一个全新的框架也。

这对于积极进取且非常有能力的程序员来说已经够难了。

【讨论】：