我已经阅读了所有关于 mvc 和 webforms 如何互补等的营销演讲......
然而，似乎所有的博客都在谈论 mvc，而唯一出来的新闻是关于 mvc。
Microsoft 是否会继续改进 webforms 作为一等公民，或者它只是一种受支持的技术，因为随着时间的推移，他们将所有真正的努力、开发人员和资源都转移到 mvc 上？
是否有任何真实证据表明在不久的将来 Web 表单会出现任何令人兴奋的新改进？
muhan
问问题
1165 次
5 回答
6
你可以比看看 Phil Haak 11 月的帖子做得更糟：
他指出了去年在 PDC 上在 ASP.NET 下宣布的 5 个关键事项：
- 核心基础架构，包括规模和性能
- Web 表单，包括客户端 ID、ViewState、CSS 使用等问题
- AJAX
- 数据和动态数据
- MVC
再加上，作为 ASP.NET MVC 的一部分构建的一些东西已经为 Web 表单发布，比如 Routing 模块，即使不使用 MVC，这对我的一些项目也会有很大帮助。
最重要的是，VS2010 中也有一些变化可以帮助 Web 开发人员使用 WebForms 或 MVC，这会很好。
博主们倾向于谈论什么是闪亮的和“新的”，事情就是这样发展的——你肯定会看到很多关于它的文字，尽管 MVC 几乎不是一种新的设计模式——它至少可以追溯到30年。
WPF/Silverlight 也是如此——它们是 WinForms/WebForms 杀手吗？不，它们是替代产品，与早期的做事方式相比有一些好处，但也有一些差异/缺点。
于 2009-02-05T17:03:54.800 回答
5
我将在这里走出困境，不同意 MVC 是这里的“企业”框架或者在某种程度上是两者中更好的一般观点。
MVC 很棒！但是只看名字。它代表“模型、视图、控制器”……看到那里的“视图”了吗？
现在看看比赛，“Web Forms”……看到那个中的“forms”了吗？
MVC 在“视图”类型的情况下做得很好。对于发布内容（信息的“视图”）的站点，MVC 可能具有优势，特别是对于需要大量测试和非常正式的设计以支持智能视图切换的大型系统。
对于通过表单与用户进行大量交互的应用程序（数据收集和数据输入繁重的应用程序），Web 表单由于固有地使用表单帖子作为主要机制而具有优势。
虽然您可以使用 Web 表单制作视图，也可以使用 MVC 制作表单，但两者都有取舍。在当前的 MVC 状态下，我发现编写繁重的数据输入“视图”比使用 Web 表单要困难得多和痛苦……而且我的意思不是一点点。
在未来，我确实希望看到 MVC 在处理数据输入场景方面做得更好，但与使用 Web 表单的场景相比，这些场景可能会付出相当高的代价。
据我所知，两者都不比另一个更“企业”级别......我最感兴趣的是混合应用程序，它使用 MVC 进行业务的显示和发布端，而更自然地使用 Web 表单对于繁重的数据输入端......都在同一个网络项目中......我当然希望我们看到类似的东西。
于 2008-10-14T12:49:12.593 回答
5
我参加了一次会议（Remix 08），Scott Gu 说他们肯定会继续支持这两种方法，并且 MVC 并不适合所有应用程序。Scott 表示，Web 表单模型即将进行一些改进（尽管没有说明它们是什么）。
Web 表单模型不会消失，因为：
Web 表单模型更适合某些类型的应用程序，例如小型应用程序，那些需要长时间进程以利用视图状态的
应用程序 许多应用程序正在使用它
许多为其开发的第三方组件
ASP.net实现还不成熟（虽然到目前为止看起来还不错）
微软可能会在几周后宣布 PDC 中的一些新功能。
于 2008-10-14T07:43:02.197 回答
5
微软终于接受了一个基本的发展事实。你无法为任何问题提供终极解决方案。这就是开发 MVC 的原因，Scott Guthrie 明确指出 MVC 适用于更大、更多企业级的站点。Web 表单将继续存在并被开发为一种简单的、基于 RAD 的 Web 开发方法。
如果您退后一步并查看 Microsoft 堆栈的所有最新改进和添加，您可以很容易地将它们分类为这两个类。例如：
- 数据访问：LINQ-to-SQL 与 EntityFramework
- 远程处理：WCF 与 WebServices
- LiveID：LiveID（Web）身份验证与 RPS 身份验证
- ...
我只希望微软会随着时间的推移将这种区别变得更加清晰，因为开发人员似乎对于应该为哪个任务选择什么工具存在很多困惑。
总之，我认为微软将继续开发这两者，因为它们迎合了不同的开发人员配置文件。微软显然对尽可能地扩大其开发人员基础以及使 .NET 堆栈尽可能有用有很大的兴趣。
于 2008-10-14T07:53:07.887 回答
0
在 MVC 框架的消息开始传播之前，我们花了很多时间在我的公司开发我们自己的 .NET MVC 框架。
这是因为我们不想被 WebForms 抽象的限制所束缚——我们想要避免 WebForms 似乎强加于大多数定制应用程序的“笨拙”感觉和用户界面妥协。此外，我们想要友好的 URI，并且我们想要比 WebForms 提供的更好的前端和后端开发分离（我们选择了 XML / XSLT 架构）。
在我看来，WebForms 实际上提供了一种更糟糕的与用户交互的方法，特别是由于使用 ViewState、PostBacks 等从开发人员那里抽象出 HTTP 的实际机制——这使得他们在允许用户方面的自由度更小与系统交互。经典的例子是，因为 WebForms 页面几乎总是 POST 的结果，如果用户尝试刷新页面，用户会从浏览器收到一个讨厌的警告消息。传统 Web 开发世界中处理这个问题的模式一直是在 HTTP 响应中包含一个 302 重定向指令，因此坚持原始的 HTTP 范式，GET 用于检索数据，POST 用于发送数据。其他，
也就是说，对于 RAD，WebForms 非常出色。我目前正在为我们使用自定义 MVC 框架开发的 web 应用程序开发管理应用程序，我正在飞速前进，因为我只需要显示大量数据库表的内容，并且在某些情况下允许用户以各种不同的方式编辑它们。
我认为，如果我们需要说服自己 MS 将继续支持 WebForms - 想想所有前 Windows 开发人员。这些是 WebForms 最初是为这些人开发的，而且他们不会消失。如果您是 WebForms 的粉丝，企业开发人员将是您的救星。
于 2009-02-04T15:06:04.133 回答