logo标签列表

ASP.NET WebForms与MVC，哪个更适合商业应用？

c#asp.net-mvcasp.net-ajaxwebforms
5

Diamonds是基于Windows Forms的ERP系统，我打算使用Web技术重新开发它，而不是Windows Forms。

但现在我需要决定哪种技术最适合这个项目，ASP.NET WebForms（我认为）更容易设计用户界面，但MVC输出的HTML更简单，并且具有其他一些功能...

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

我正在使用C#语言，

谢谢。

7个回答
6
如果您关心应用程序的可扩展性、易维护性、可伸缩性和健壮性，以及软件开发技能的发展，那么请尽可能远离Web表单。将所有内容都包装在表单中添加状态层的整个想法是错误的。HTTP是无状态的，MVC建立在该模型之上，这是好的。
关于评论所说的内容。 Web表单应用程序不具有可扩展性，因为表示层、业务逻辑和数据访问代码（数据源）都驻留在代码后面。 Web表单提供的控件仅适用于Web表单。这意味着您将无法将这些技能转移到另一个Web开发框架中。
最后，当然可以使用MVC编写紧密耦合的应用程序-总有一种方法来摧毁某些东西。对此没有争论。主要问题是MVC鼓励分离关注点和单一责任原则，而Web表单实际上会使其消失。
您还说Web表单更容易。如果您一直在使用它，并且与MVC相比，它更快地掌握，那么它确实更容易。但是，在长期运行中，MVC很可能变得“更容易”。观看www.asp.net/mvc上的几个视频。此外，您可能需要了解测试驱动开发（单元测试）。我认为单元测试与Web表单不兼容，因为所有内容都紧密耦合。如果我错了，请纠正我。
我非常想听听其他有使用两个框架的开发人员的意见。
3
这个回答很准确。你会看到一些人支持争论的双方，但作为一个长期从事WebForms开发并最近全身心投入MVC的人，我可以诚实地说，我再也不想写WebForms应用程序了 :) - stephen776
1
在我看来，MVC 明显更好，但你列举的所有理由都与底层框架无关，而是取决于开发人员交付的代码质量。可扩展性也是如此，它与 Web 前端无关，而始终取决于底层数据服务。一个 MVC 网站如果数据库超载，就像一个 WebForms 数据库一样慢。 - John Farrell
1
@vikp - “Web forms 应用程序不可扩展，因为演示层、业务逻辑和数据访问代码（数据源）都驻留在代码后面。” - 不，那完全是错误的。这完全取决于应用程序的编码方式，你同样可以将所有这种类型的代码放在控制器内部。 - John Farrell
1
@vikp - "MVC 鼓励关注点分离和单一职责原则，而 Web Forms 实际上会削弱它们。" - 什么？Web Forms 如何削弱 SOC 和 SRP？我见过很多良好的 Web Forms 代码，看起来与构建良好的控制器非常相似。 - John Farrell
@vikp - 我也非常关注MVC...但是正如jfar指出的那样，你的回答充满了误解... - B Z
你能举些例子吗？ - user338195
5
我认为在掌握基础知识后，这两种技术都会变得有点复杂。以下是我在实施一个必须在MVC和WebForms主机中运行的项目时收集到的一些简要意见。
WebForms优点：
  1. 产品的成熟度
  2. 关于复杂控件的第三方支持很多
  3. 有办法绕过框架中遗留的感觉方面（例如WebForms MVP）
WebForms缺点：
  1. 页面生命周期问题可能会让您非常生气；复杂web应用程序有很多移动部分
  2. 使用依赖注入“难以”使用/实现
  3. 框架中有很多东西是您无法控制的
  4. 需要像Reflector这样的工具来深入研究反编译源代码，以解决文档、网络、实验无法回答的问题。
MVC优点：
  1. 关注点分离很好，支持依赖注入
  2. 对许多事情有更多的控制权（例如项目结构、MVC框架、渲染内容等）
  3. 您可以将应用程序与MVC框架一起复制部署到asp.net 4安装上（例如第三方托管提供商）
  4. 原生支持JSON
  5. 提供源代码（带有注释！），以便在遇到内部问题时深入了解各种功能。
  6. 他们一直在进行工具的外部发布，我相信计划在框架上这样做（？）；他们还有一个未来项目和源代码，展示了他们正在前进的一些方向，如果您选择使用，可以利用它们。

MVC缺点：

  1. 需要一些时间来理解
  2. 没有像WebForm那样成熟的第三方帮助程序（没有控件）；现有的那些似乎不如它们的WebForm同行精细

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

使用依赖注入是“难以”使用/实现的 - 为什么？将依赖项注入到“Page”中非常容易，并且类似于设置控制器工厂。http://aspnetresources.com/articles/ioc_and_di_with_web_forms - John Farrell
抱歉，但对于我来说，使用nuget将ninject“安装”到我的mvc项目中（然后使用WebActivator无缝注入依赖项到我的控制器）比实现自定义PageHandlerFactory更直观。 我有一个部分在mvc中运行，部分在webforms中运行的解决方案，最终为webforms使用了ServiceLocator模式。 我无法更改控件/页面的基类，并且希望保持简单。 一定可以让它正常工作，但我发现设置MVC更容易。 - Jason
@Jason - 有一个专门为WebForms开发的Ninject NuGet包。不清楚它与MVC相比有何不同或更直观之处。 - John Farrell
嗨@Jfar，是的，有的，但它需要页面/控件必须继承的要求。我对ninject和ASP.NET主机中的DI是新手，所以可能是我无法理解它。Webforms是一项伟大的技术。作为一个Ninject新手，我发现MVC更容易设置和运行，关于DI。这对我来说很有意义，因为它是为此而设计的。(http://bradwilson.typepad.com/blog/2010/07/service-location-pt1-introduction.html) - Jason
@Mustafa，太棒了！MVC与事件驱动模型完全不同。你基本上在网页（视图）上创建一个操作链接，并映射到控制器上的一个操作。最好的方法是查看asp.net网站上的教程。http://www.asp.net/mvc 对我来说这是最有帮助的（特别是创建一个小应用程序）。此外，寻找Scott Hanselman的文章。最后，请确保您正在使用mvc v3。它不是默认安装在VS2010上的（因为它是发布于vs2010之后），所以您需要下载和安装。 - Jason
显示剩余2条评论
4
我强烈推荐MVC，因为一旦UI被解决，它会从后端的角度使开发变得更加容易。有很多mvc vs asp的问题： 1, 2, 3 从我的角度来看，MVC仅凭TDD和无Viewstate就能赢得胜利。但它确实取决于您计划如何管理和使用两者的各种功能。
2
1

虽然我已经完成了许多关于 Web 表单的项目，但我必须说它们存在的主要原因是为了在无状态协议上提供一层抽象，从而大大促进基于事件的模型。不幸的是，就像大多数 MS 解决方案一样，这是有代价的。

历史上，Web 表单曾经饱受标记生成问题的困扰。其中一些问题至今仍然存在，特别是涉及 ViewState 的问题。现在情况稍微好一点了（你可以在 ASP .NET 4.0 中管理 DOM id），但是 Web 表单仍然会给你带来烦恼。在 Web 表单项目中常见的事情是将大量业务逻辑隐藏在 codebehind 中。

MVC 并不能消除这个问题，但它提供了一种结构和关注点分离的方式，使不良实践变得不太可能。尽管如此，默认的视图引擎更擅长从终端用户的角度生成干净的标记，但视图中的内联代码还是传统 ASP 的回归。

值得一提的是，我已经停止开发 Web 表单项目，并专门转向 MVC 进行新的工作。

1

在我看来，MVC

我不得不写一份报告来证明从Web Forms/Nettiers转换到MVC的必要性

我在博客这里中列举了我的观点

0

这完全取决于你的选择。使用Web Forms可以让你更轻松地设计应用程序，而MVC现在已成为行业标准，甚至微软也大力推广它。如果你想保持代码的清晰度，那么毫无疑问MVC是更好的选择。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接