您是否计划从ASP.NETWeb表单转移到ASP.NETMVC？

如果是，什么时候？您认为迁移当前项目的过程需要多长时间（如果是这样的话）？

不，没有理由这样做。这是另一种风格，我不喜欢。但这只是我的观点；很多人都喜欢它，我希望它能很好地为他们服务。

对我的新项目来说是的。但不适用于当前的生产软件。

假设您更喜欢ASP.NET MVC而不是Web表单，那么对于处于动态开发/维护中的系统来说，这是值得的

它们可以并排共存，因此可以迁移应用程序的某些部分（新的或选定的旧的），并查看其效果。如果成功了，就继续

---

“全有或全无”的迁移可能是灾难性的，但在没有快速反馈的情况下大量投资是一个巨大的风险。

ASP.NET MVC并不意味着要取代WebForms。它们是不同的技术，用于不同的目的

笼统地说我只使用其中一种而不使用另一种是一种非常狭隘的做法，因为你忽略了每种技术的优缺点

微软致力于这两种技术的发展，WebForms4.0中有很多新的功能

---

我将使用WebForms和ASP.NET MVC，但要考虑当前项目的需求，以便为当前的实现做出正确的决策

是的，尽可能有序地进行

MVC为.NET打开了敏捷开发最佳实践的大门。它具体解决了关于关注点分离和耦合/内聚的关注点。它还允许我们编写更具可移植性的软件，而无需依赖任何特定于供应商的引用或组件

毫无疑问，是WebForms和WPF的继承者，不管你读到什么公关

---

非常清楚，甚至在为微软的MVC更新之前。

我已经用了几个月了。我绝对喜欢MVC。根据可用时间，转换现有项目可能不现实。在我看来，Web窗体模拟了旧VB群体的windows窗体开发。尽管MVC并不假装它不是什么，而是更密切地遵循Http过程

我在MVC中看到的一些优点

1） 它可以通过单元测试进行测试

2） 对Html的直接控制。我们制作网站，我们如何接受不能控制所有html

3） 无可视状态行李

4） 没有浪费渲染时间的控件树

5） 从表单发布自动绑定模式

6） 它可能相当性感

还有一些缺点

1） 不再有web控件（许多丰富的第三方控件丢失）

2） 发展缓慢

3） 大学习曲线

---

4） 仍处于Beta测试阶段（不过很快会有CTP）

我限制了轻量级前台网站的ASP.NET MVC

---

但是仍然使用ASP.NET WebForms作为Righ BackOffice应用程序，以利用丰富的自定义控件和Web表单的其他一些优秀功能。

正如前面所说，它们不是相互排斥的，我会充分利用两者

IMO MVC更适用于web站点，而WebForms更适用于web应用程序

例如，由于网站的性质和需要完成的工作，该网站是一个展示ASP.NET MVC是一个不错选择的完美窗口；其他好的例子是网络商店、项目管理网站（如Basecamp）或社交网络

但是，如果您正在开发企业CRM/ERP系统，我会坚持使用WebForms来获得丰富的控件和更“类似桌面”的编程模型，因为CRM应用程序传统上是桌面应用程序的领域

WebForms用于丰富的UI

MVC或Webforms也可以这样做。一年后，丰富的基于MVC的工具包将会出现（如果您喜欢YUI、ExtJS等，从技术上讲，它们已经在这里了），并使这个论点无效

迁移当前项目

---

将现有的WebForms项目迁移到MVC没有多大意义。你会得到什么？然而，在一个新项目中使用MVC会有很大的意义，这取决于您的需求。

我已经使用ASP.NET MVC几个月了，我更喜欢它而不是Web表单。然而，我并没有看到自己将现有项目迁移到MVC。对我来说，这是毫无意义的。然而，我的所有新ASP.NET项目都将（或应该）使用MVC开发，因为它是一个更好（更灵活）的框架。

MVC的另一个优点是，像jquery这样的javascript更容易实现，因此如果您计划使用大量js，mvc可能是一个不错的选择。

一开始我从来都不太喜欢WebForms，所以使用mvc对我来说就像呼吸了一口新鲜空气。我一直更喜欢关注点分离，因为我可以处理我非常擅长开发的块、逻辑和数据访问，并将演示工作留给具有这种天赋的团队成员。我认为MVC库使团队更容易在单个页面上协同工作，因为一个人可以在控制器上工作，另一个人可以在视图上工作

---

尽管如此，当我在做一些项目时，我不需要太多地关注编码，而且它更面向显示，我还是会回到WebForms，因为它们更容易实现、启动和运行。两者都有各自的位置，我不认为其中一个会取代另一个。

ASP.NET MVC更适合我所期望的开发风格，但我很谨慎，在它不是RTM的时候，我不会相信自己。它也非常不同，以至于我们的遗留代码无法使用它。如果我们一直在实践领域驱动的开发，事情可能会更容易，但是…

一样。新职业选手