我们讨厌经典asp的东西，但今天仍然存在于webforms中

Question

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

如：

Spagetti Code （违反SRP）

经典ASP - 每个.asp文件都像一个大球泥 Webforms - 这个泥泞的大球从视野变为臭名昭着的“代码隐藏”

请记住，我的开发人员不是实现类似MVP的类型，而不是被推送，这也是我喜欢MVC的原因之一（尽管保持控制器很薄，这将是一种学习体验）

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

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

我一直在寻找有人指出平均9-5开发人员“想要”在他们编写经典asp之后逃避的事情，但是在他们进入we​​bforms之后从未完成过。 （再一次 - 我工作的大多数开发人员只是把他们在经典asp中抱怨的混乱局面转移到后面的代码中，并且“认为”这是朝着正确方向迈出的一步。）

Answer 1

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

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

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

Answer 2

在我的诚实意见中，你正在寻找错误的理由进行转换。迁移到ASP.NET MVC不会解决任何这些问题。如果不是更多的意大利面条代码（或泥球）作为经典ASP或Webforms，仍然可以拥有一个巨大的视图。

您的谈话要点应该更多地考虑到关注点，友好的URL（Webforms中也有），对页面的更多控制等等。

你也可以查看微软的这篇博文：

Web Forms vs. ASP.NET MVC

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

  

ASP.NET MVC不是反Web表单

他们都有正确的用途。由于编码不良而从另一个切换到一个并不会有帮助。你可以在任何一个......

中做到这一点

Answer 3

问题的一部分是，你可以很容易地将“Spaghetti Code”和“泥球大”与MVC视图写得很糟糕 - 如果你说这将是一个“学习经验”，保持你的控制器很薄，那么你将很难保持你的意见干净整洁。

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

---

编辑以回答问题的修改

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

1. 必须记住设置ViewStateEnabled = false以减少页面大小。
2. 几乎无法控制客户端ID的控件（这将在ASP.NET 4.0中解决，但您可以在其中设置ClientID）。
3. 几乎无法控制呈现的控件HTML（尽管可以使用CSS控件适配器来缓解这种情况，它将内置于ASP.NET 4.0中，并且是我认为的默认行为。）

在构建基于MVC的网站时，我非常欣赏这些对我而言的主要内容。

Answer 4

  

我工作的大多数开发人员都搞砸了   他们在经典的asp中抱怨并把它移到了   代码背后和“思想”这是右边的一步   方向）。

嗯，它是朝着正确方向迈出的一步 - 比完全没有分离更好。虽然，是的，它仍然经常是泥泞的球。

在我乐观的时刻，我认为很好，也许它只是将球形泥浆移到了代码隐藏处，但也许它植入了“嗯，也许内容应该与展示分开！”的种子。在某些人看来。 MVC或类似的模型当然是他们最终会到达的目的地。

（不要问我在非乐观时刻的想法......哈哈。）

Answer 5

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

MVC框架无法解决团队在工作中学习和利用优秀设计原则的问题。但是当前形式的MVC框架将为他们的板块增加额外学习的LOI。 MVC框架没有太多的RAD功能，正确使用它需要深入了解Http本身的性质。

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

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

对于具有高度积极性和能力的程序员来说，这很难。