我们有一个基于WebForms的Web应用程序，它具有以下属性：
大型业务对象框架（Close knit DAL / Business Objects / Serverside验证，类似于CSLA）预编译并放置在Bin文件夹中。使用了很多UserControls。
看一下MVC的概述，似乎对代码如何拆分存在明显的分歧，没有会话状态（这似乎很奇怪，但如果网站主要提供内容可能还可以？）并且它似乎构建页面看起来类似于经典的asp（使用＆lt; %%＆gt;标签）
我对MVC有错误的解释吗？ MVC只是一个特定的架构，或者是事情的发展方式，WebForms最终会被删除？ 当现有的业务对象框架存在时，如何拆分M-V-C？ 为什么没有会话状态？ UserControls在MVC中工作吗？
我意识到这可能是主观的，所以主要是在寻找你对这个主题的评论，以便我自己的想法。
答案 0 :(得分：11)
MVC与WebForms的90％+相同，但当然每个人都在进行辩论时，他们往往会把这个问题留下来。
您可以根据需要提供任意数量的图层，是的，您可以执行UserControl样式。这更像是一种思维方式的改变而不是技术的改变。 MVC有它的优点，它包含HTTP 是stateleess 的事实。 Webforms在一定程度上抽象了这个事实，使一些事情变得更容易（例如，查看状态）。会话状态，编译......就在那里，它位于两者之下的同一框架中。
简而言之：使用您想要的东西，研究得很好（示例项目无处不在）。如果你深入研究项目，需要及时考虑转换，它是学习曲线以及实际的代码时间。 这个决定取决于你和你的团队，如果它太不同了，那么它可能不是很有益，因为有一些调整。如果您对新技术更加满意，MVC可以更清洁...... 两者仍然有其用途。
我不会在WebForms中启动另一个项目，但那是 me ，我很满意......你真的必须弄清楚哪种感觉更自然，如果适用的话，你的团队。
此外，tvanfosson提出了一个很好的观点：之前的Web项目中的验证或其他自定义逻辑越多，移动所需的时间就越多。如果你已经拥有了很好的层次分离，那么你处于更好的位置，如果没有，这是另一个主要的时间考虑。
答案 1 :(得分：6)
听起来您的域模型和演示文稿之间存在很多耦合。如果是这样的话，需要进行大量的重新设计。 MVC确实支持Session状态，但它不使用ViewState - 听起来你有点混乱。它不支持普通的UserControl或任何依赖于ViewState的东西。您可以为MVC创建“控件”（称为“部分”视图），以便功能存在，但形式不同。在MVC中，您的视图与业务模型非常分离，通常您将拥有一组特定于视图的模型，这两个模型在两者之间进行调解，并且视图是强类型的视图模型，而不是业务模型。
虽然我建议将MVC作为基于Web的应用程序的更好架构，但在你的情况下，我不确定切换是否有意义（至少现在）。我建议坚持使用WebForms（根据Scott Hanselman不会消失）或者从新功能（或应用程序）开始慢慢迁移到MVC。
答案 2 :(得分：2)
MVC是一款闪亮的新瓶装，适用于同样的旧酒，即网络和酒。它的工作方式。
另一方面，你最终可以远离asp.net viewstate＆amp;页面生命周期，回发，疯狂的URL等。
如果您需要从webforms转移到MVC，请查看您可能在应用程序UI中使用的第三方控件的依赖性。并非所有供应商都拥有MVC等价物。会话和ViewState是在UI端查看的其他最重要的方面。如果您有一个面向公众的Web应用程序，请考虑URL被加入书签。所有这些可能是迁移到MVC时要考虑的其他因素。
通常，我建议首先将您的代码分解为模型 - 控制器层＆amp;完成后，将UI更改为View＆amp;使用MVC的URL路由机制。或者，您可以使用任何体面的URL重写模块＆amp;首先发布REST样式的URL＆amp;将旧网址重写为新网址＆amp;然后慢慢将应用程序的各个部分转换为MVC。