最适合商业应用程序的 asp.net webforms vs mvc [关闭]答案

【问题标题】：asp.net webforms vs mvc which is best for business applications [closed]最适合商业应用程序的 asp.net webforms vs mvc [关闭]
【发布时间】：2011-09-12 10:36:44
【问题描述】：

Diamonds 是一个基于 Windows 窗体的 ERP，我将使用 Web 技术而不是 Windows 窗体重新开发它..

但现在我需要决定哪个最适合这个，ASP.NET webforms（我认为）更容易（设计）我的意思是 UI，但mvc 具有更简单的 html 输出和一些其他功能...

您能帮我决定使用哪种技术以及为什么使用吗？

我正在使用 C#，

干杯

【问题讨论】：

标签： c# asp.net-mvc asp.net-ajax webforms

【解决方案1】：

如果您关心应用程序的可扩展性、易维护性、可扩展性和稳健性，以及软件开发技能的发展，那么请尽可能远离 Web 表单。

通过将所有内容包装在表单中来添加状态层的整个想法是错误的。 HTTP 是无状态的，而 MVC 是围绕该模型构建的，这很好。

编辑关于制造的cmets。 Web 表单应用程序不可扩展，因为表示层、业务逻辑和数据访问代码（数据源）都驻留在代码后面。 Web 表单提供的控件仅适用于 Web 表单。这意味着您将无法将这些技能转移到另一个 Web 开发框架。

最后，当然可以使用 MVC 编写紧密耦合的应用程序 - 总有办法破坏某些东西。对此没有任何争论。重点是 MVC 鼓励关注点分离和单一职责原则，而 Web 表单实际上将其从您手中夺走。

您还说过 Web 表单更容易。如果您一直在使用它会更容易，并且与 MVC 相比，它的上手速度更快，但是，从长远来看，MVC 可能会变得“更容易”。在 www.asp.net/mvc 上观看一些视频。此外，您可能想研究测试驱动开发（单元测试）。我不认为单元测试适用于 Web 表单，因为一切都是如此紧密耦合的。如果我错了，请纠正我。

我很想听听其他有使用这两种框架经验的开发人员的意见。

【讨论】：

这个答案是正确的。你会看到支持双方争论的人，但作为最近一头涉足 MVC 的长期网络表单开发人员，我可以诚实地说，我再也不想写另一个网络表单应用程序了 :)
恕我直言，MVC 显然更好，但您引用的所有原因都与底层框架无关，而是从开发人员交付的代码质量中获得的。可扩展性也与 Web 前端无关，但始终依赖于底层数据服务。具有重载 db 的 MVC 站点与 Webforms 数据库一样慢。
@vikp - “Web 表单应用程序不可扩展，因为表示层、业务逻辑和数据访问代码（数据源）都驻留在代码后面” - 不，完全错误。这完全取决于应用程序的编码方式，您可以轻松地将所有此类代码包含在控制器中。
@vikp - “MVC 鼓励关注点分离和单一职责原则，而 Web 表单实际上将其从您手中夺走。” - 什么？网络表单如何带走 SOC 和 SRP？我见过很多优秀的 Web 表单代码，它们看起来与任何构造良好的控制器都非常相似。
@vikp - 我也很喜欢 MVC……但正如 jfar 指出的那样，你的回答充满了误解……

【解决方案2】：

我认为这两种技术在通过任何基础知识后都会变得有点复杂。以下是我在实施必须同时存在于 MVC 和 WebForms 主机中的项目时收集的一些简短意见。

WebForms 正面评价：

产品的成熟度
在复杂的控制方面有很多第 3 方支持
有一些方法可以绕过框架的遗留问题（例如，WebForms MVP）

WebForms 否定：

页面生命周期问题可能会激怒您。一个复杂的网络应用程序有很多移动部件
使用依赖注入“难以”使用/实现
框架中有很多东西是你无法控制的
当遇到文档、网络、实验无法回答的问题时，需要像 Reflector 这样的工具来深入研究反编译的源代码。

MVC 正面：

极大的关注点分离和对依赖注入的支持
对许多事物（即项目结构、mvc 框架、渲染内容等）进行更多控制
您可以将您的应用程序与 mvc 框架一起部署在 asp.net 4 安装之上（即第三方托管服务提供商）
原生支持 JSON
提供了源代码（带 cmets ！！），以便您在遇到内部问题时可以深入了解各种功能。
他们一直在进行工具的带外发布，我相信计划在框架上这样做（？）；他们有一个未来项目以及向您展示他们正在发展的一些方向的源代码，如果您愿意，您可以利用它们。

MVC 否定：

可能需要一点时间来思考一下
没有那么多的第 3 方助手（无控件）；现有的那些似乎不如 WebForm 对应的复杂

就我个人而言，我是 MVC 的粉丝，因为它具有可控性、灵活性和透明的依赖注入支持。也许您应该对这两种技术进行一次小型试验，看看您更喜欢哪一种。祝你好运，玩得开心！

【讨论】：

“使用依赖注入是“难以”使用/实现的” - 怎么样？将依赖项注入Page 非常简单，类似于设置控制器工厂aspnetresources.com/articles/ioc_and_di_with_web_forms
对不起，但对我来说，使用 nuget 将 ninject “安装”到我的 mvc 项目中（然后使用 WebActivator 将依赖项无缝注入到我的控制器中）比实现自定义 PageHandlerFactory 更直观.我有一个解决方案，部分在 mvc 中运行，部分在 webforms 中运行，我最终使用了 webforms 的 ServiceLocator 模式。我无法将基类更改为我的控件/页面，我想保持简单。绝对可以让它工作，但我发现 MVC 更容易设置。
@Jason - 有一个用于网络表单的 Ninject nuget 包。看不出这与 MVC 有何不同或更直观。
嗨@Jfar，是的，但它有页面/控件必须继承要求。我是 ASP.NET 主机中的 ninject 和 DI 的新手，所以我可能无法完全理解它。 Webforms 是一项伟大的技术。作为一个 Ninject 菜鸟，我发现 MVC 更容易让我设置和运行 wrt DI。这对我来说很有意义，因为它的设计考虑到了这一点。 (bradwilson.typepad.com/blog/2010/07/…)
@Jason，你的回答很好，但我需要再澄清一下，我曾经在 webforms 中使用事件驱动生命周期，在 MVC 中是否足够简单，如果你能给我一些教程，这会有所帮助；干杯

【解决方案3】：

我强烈推荐 MVC，因为一旦 UI 被解决，从后端的角度来看，它使开发变得非常容易。那里有大量的 mvc 与 asp 问题： 1, 2, 3

在我看来，MVC 仅基于 TDD 而没有 Viewstate 获胜。但这实际上取决于您计划如何管理和使用两者的各种功能。

【讨论】：

【解决方案4】：

我认为this post from Scott Guthrie 读起来真的很有趣。阅读后，我认为您很可能会选择 ASP.NET MVC。 :-)

【讨论】：

【解决方案5】：

虽然我用 Web 表单完成了很多项目，但我不得不说，它们存在的主要原因是在 HTTP 上提供一个抽象层，主要是为了在无状态协议上促进基于事件的模型。不幸的是，与大多数 MS 解决方案一样，这是有代价的。

从历史上看，Web 表单过去常常受到与标记生成相关的问题的困扰。其中一些问题今天仍然存在，尤其是在涉及 ViewState 时。现在情况稍微好一些（您可以在 ASP .NET 4.0 中管理 DOM id），但 Web 表单仍然会让您感到悲伤。您将在 Web 表单项目中看到的常见事物是隐藏在代码隐藏中的大量商业逻辑。

MVC 并没有消除这一点，但它提供了一种结构和关注点分离，从而降低了不良做法的可能性。也就是说，尽管从最终用户的角度来看，默认视图引擎更擅长生成清晰的标记，但视图中的内联代码是对经典 ASP 的回归。

不管怎样，我已经停止开发 Web 表单项目，而是专门转向 MVC 进行新工作。

【讨论】：

【解决方案6】：

恕我直言MVC

我必须写一份报告来证明从 Web Forms/Nettiers 更改为 MVC 的合理性

我在博客上写了我的论点here

【讨论】：

【解决方案7】：

这完全取决于您的选择，拥有 Web 表单可以让您轻松设计您的应用程序，因为 MVC 现在已成为行业标准，甚至 MS 也在大力推广它。如果你想保持你的代码干净，那么毫无疑问 MVC 是更好的选择。

【讨论】：