C# ASP.NET、WebForms 到 MVC：在我们的案例中进行更改是否有意义？答案

【问题标题】：C# ASP.NET, WebForms to MVC : Does it make sense to change in our case?C# ASP.NET、WebForms 到 MVC：在我们的案例中进行更改是否有意义？
【发布时间】：2011-01-14 02:07:53
【问题描述】：

我们有一个基于 WebForms 的 Web 应用程序，具有以下属性：

大型业务对象框架（Close knit DAL / Business Objects / Serverside Validation，类似于 CSLA）预编译并放置在 Bin 文件夹中。使用大量的用户控件。

查看 MVC 的概述，似乎在代码拆分方式上存在明显差异，没有会话状态（这看起来很奇怪，但如果网站主要提供内容可能还可以？）并且它似乎正在构建页面看起来类似于经典的 asp（使用标签）

我对 MVC 有错误的解释吗？ MVC 只是一种特定的架构，还是事情会这样发展，WebForms 最终会被丢弃？当现有的业务对象框架存在时，如何拆分 M-V-C？为什么没有会话状态？ UserControls 可以在 MVC 中工作吗？

我意识到这可能是主观的，所以主要是在这个主题上寻找你的 cmet 来做出我自己的决定。

【问题讨论】：

ASP.NET MVC 不会阻止您使用会话状态。它只是一种制作 ASP.NET 应用程序的模式。
@Hasan：谢谢，不知道为什么我认为是这种情况......

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

【解决方案1】：

MVC 与 WebForms 有 90% 以上的相同，但当然，当每个人都进行辩论时，他们往往会忽略这些花絮。

您可以在下面设置任意数量的层来提供您的数据，是的，您可以使用 UserControl 样式。这更像是一种思维方式的改变，而不是技术的改变。 MVC 有它的优点，它包含 HTTP 无状态这一事实。 Webforms 在一定程度上抽象了这一事实，也使一些事情变得更容易（例如视图状态）。会话状态、编译……都在那里，它们都在同一个框架中。

简而言之：使用你想要的，好好研究它（示例项目无处不在）。如果您深入到一个项目中，请考虑转换时间、学习曲线以及实际的代码时间。 这个决定取决于您和您的团队，如果差异太大，则可能不是很有用，因为需要进行一些调整。如果您对新技术更熟悉，MVC 会更简洁...两者仍有其用途。

我不会在 WebForms 中开始另一个项目，但那是我，我觉得很舒服...你真的必须弄清楚哪个对你来说更自然，如果适用，你的团队。

另外，tvanfosson 提出了一个很好的观点：验证越多，或者实际上之前 Web 项目中的任何自定义逻辑，转移所需的时间就越多。如果您已经有很好的层分离，那么您可以更好地做到这一点，如果没有，那是另一个重要的时间考虑因素。

【讨论】：

+1。这是我见过的对此类问题的最明智的回答。
如果他们已经在自定义 UserControls 中构建了很多模型（包括验证），那么这将是一个比您所说的更大的变化——IMO 是一个完整的重新架构。
@tvanfosson - 很好，在其中添加了该注释。我认为这完全取决于他们当前的架构是什么。对于我遇到的大多数 WebForms 项目，我必须同意你的看法……这确实是代码的主要部分。
...有哪些特定的 WebForm-to-MVC 问题，例如用户控件是否没有 OnLoad/OnPreRender 事件等，这些需要重新完成吗？
@Mark - 实际上，根本没有页面生命周期，至少，不是你目前所想的那样。这个 SO Question 对此有很好的答案：stackoverflow.com/questions/460145/…。您可以使用可移植代码、母版页（实际上是用户控件）等制作用户控件。不过，它们的使用方式略有不同：matthidinger.com/archive/2008/02/21/…

【解决方案2】：

听起来您的域模型和演示文稿之间有很多耦合。如果是这样的话，将需要大量的重新架构。 MVC 确实支持 Session 状态，但它不使用 ViewState ——听起来你在那里有点困惑。它不支持普通的 UserControls 或任何依赖于 ViewState 的东西。您可以为 MVC（称为“部分”视图）创建“控件”，以便功能存在，但形式不同。在 MVC 中，您的视图与您的业务模型非常分离，通常您将有一组特定于视图的模型在两者之间进行调解，并且视图是视图模型的强类型，而不是业务模型。

虽然我会推荐 MVC 作为基于 Web 的应用程序的更好架构，但在您的情况下，我不确定切换是否有意义（至少现在是这样）。我建议要么坚持使用 WebForms（根据 Scott Hanselman 的说法，它不会消失），要么从新功能（或应用程序）开始慢慢迁移部分内容到 MVC。

【讨论】：

关于视图状态/会话状态的好点，肯定在那里混淆了。显然来自 WebForms，我们对 SessionState 和 ViewState 有明确的用途。如果我们继续使用 Session State 没关系...但是如果我们没有 ViewState 并且我们正在对表单进行多次回发，我们是否需要回到我们在 Cliassic ASP 中使用的所有技巧（即存储值在 URL 上并根据它们的 Form[] 值读取值？例如，当 TextBox 在页面上时会发生什么情况，仍然可以读取 TextBox1.Text 值吗？
MVC 中没有服务器端控件。您通常通过模型绑定到操作参数来获取数据，或者直接从请求（或通过值提供者）获取数据。您会发现整个范例是不同的——一方面，您可以每页有多个表单，每个表单都返回到它自己的操作。这也是，IMO，更容易使用 AJAX，因此缺少状态并不那么重要，因为您将用户留在页面上并在后台异步处理请求 - 不需要整个表单的往返。

【解决方案3】：

MVC 是一款闪亮的新酒瓶，适用于网络及其工作方式相同的旧酒。

另一方面，您终于可以摆脱 asp.net 视图状态和页面生命周期、回发、疯狂的 URL 等。

如果您需要从 Web 表单迁移到 MVC，请查看对您可能在应用程序 UI 中使用的第三方控件的依赖性。并非所有供应商都具有 MVC 等价物。 Sessions 和 ViewState 是在 UI 端查看的其他最重要的方面。如果您有一个面向公众的 Web 应用程序，请考虑将 URL 加入书签。所有这些都可能是迁移到 MVC 时需要考虑的额外因素。

通常，我建议首先将您的代码分解为模型控制器层，一旦完成，然后将 UI 更改为视图并使用 MVC 的 URL 路由机制。或者，您可以使用任何不错的 URL 重写模块并首先发布 REST 样式的 URL，然后将旧 URL 重写为新 URL，然后慢慢将应用程序的部分转换为 MVC。

【讨论】：

关于第 3 方控件的要点。我们在后端使用了相当多的各种东西，实际上已经为我们自己的 UserControl+jQuery 组件放弃了一个全面的 UI 控件库以减少开销。