我们认为ASP.NET MVC是否会在Microsoft Web开发市场中占有重要份额？还是会更像是10-15％的市场？

解决方案

我认为由于webforms安装基础的原因，这将是一个缓慢的开始。随着单元测试和标记控制对更多人开始变得越来越重要，那么我认为我们开始看​​到迁移。我怀疑它是否会达到Web平台的MS安装基础的100％，但是在未来几年中它将稳定增长。将会有一些狂热的男孩们说这将统治星球片面包，但这是不现实的。因此，我希望不必长时间使用Webforms。

EDIT:  Now that we are at Beta 1 we are starting to see the component vendors start to ship some stuff.  Looks like first up to bat is Telerik with their ASP.NET Ajax Controls in ASP.NET MVC

哦是的。这将使Web表单泛滥成灾，我们已经看到了真正的MVC框架在Java世界中的价值。在MS世界中，确实是一个需要填补的空白。

作为Java / Struts的前身，我发现在Web表单中进行当前工作非常令人沮丧，因为我知道那里提供的工具可以使我的生活变得如此轻松。

我不这么认为。两种解决方案的目的和目标都不相同，APS.NET Web Forms更像一个平台，而MVC是体系结构框架，因此这个问题有点奇怪。在我看来，MVC与良好的AJAX支持以及正确的服务器端模型结构相结合可能是开发Web应用程序子范围的更方便的方法，但是Web Forms不会消失，它们将在下一版本中进一步改进。

干杯。

我认为，最终，MVC将在MS网络市场中占有100％的份额。好多了。

MVC非常棒，但除非它包含自己的丰富控件集，否则它不会真正替代Web Forms。我们可能已经知道，某些现有控件可以使用它，但是许多控件却不能。尽管如此，我仍然喜欢使用它。

正如Ty所言，只有在控件存在之前，才会被广泛采用。我确实认为一旦完成，它将超越Web表单。一旦我们需要做一些复杂的事情并且很难进行测试，那么webform模型就会变得过于分散。对MVC进行单元测试的能力非常强大，但是人们只是不知道他们还缺少什么。

我认为ASP.NET MVC是ASP Classic(很多渲染控件)和ASP.NET(具有实际体系结构和缺少意大利面条代码的能力)的最佳选择。

嗯，.NET从未能够完全抵抗Visual Basic 6的惯性(我仍然在这里和那里看到一些商店刚刚开始转向.NET)，因此必须考虑ASP.NET Webforms的惯性以及目前如何将其部署到任何地方。

毫无疑问，ASP.NET MVC将得到广泛的采用，但这将由对架构师敏感的类型所推动：某些经理和步伐不快的开发人员不会在意。

我认为喜欢这种开发模型的开发人员会采用它，但是我更喜欢Webforms，因为生命周期提供了一种创建可重用控件的好方法。

而且，我们还可以通过Web表单维护MVC开发风格，并能够为所有代码创建单元测试，因此，可测试并不是MVC更好的理由。

我的猜测是，如果我们对TDD，REST，编写自己的HTML等感兴趣，那么MVC是"经典" Webform编程的替代解决方案。
目前，开发人员仍然喜欢D＆D开发风格，因为它允许快速开发应用程序，即使这样也变得难以维护。
随着越来越多的人开始采用敏捷方法，并且对编写可维护的软件(而不是开发快速，肮脏的应用程序)越来越感兴趣，MVC将获得更多的用户基础。
在一次演讲中，我记得ScottH说过他们认为MVC会浮动5-10％，

我的猜测是，在企业大范围困扰微软之前，微软真的必须站出来说" MVC是我们应该做Web应用程序的唯一方法"。因此，目前的用户群还不多。

我直到最近才开始使用MS的MVC框架。我从Preview 5的发布中开始接触到很多东西。促使人们使用它的最大障碍是缺少示例和有用的参考资料。

框架本身是一个很棒的使用经验，尤其是与jQuery和nUnit结合使用时。从面向对象的角度来看，我们网站的设计变得更加自然，我认为，一旦使用广泛可用的优质入门材料来减少学习曲线，那么它将逐渐成为使用MS产品进行Web开发的主要体系结构。

我认为更多的人了解Model View Controller的重要性以及简单的Page Controller的局限性，而ASP.Net表单正是这种局限性。

正如有人指出的那样，问题是我们认识的Visual Basic专家来自经典的ASP经验，却从未见过任何单元测试和/或者基于MVC的Java / Ruby / PHP开发。我相信那是大量的.NET开发人员。我在某处读到，全世界有600万个VB开发人员。猜猜，这些现在在做什么？

来自Java / Ruby / PHP商店的人已经习惯了MVC应用程序，他们一定会适应MS MVC框架。

我认为对于那些没有代码背后范式经验的人来说，Web表单可以满足他们的安全/舒适需求。我并不是说这很糟糕，因为对于许多业务任务而言，目标是完成任务并付诸实践。不幸的是，业务与结果有关，很多时候我们不得不忽略方法。

另一方面，当情况确实需要页面之间进行复杂的交互时，Webforms会为所有变通办法带来极大的复杂性。注册脚本块只是为了能够触发javascript？当我们想通过Windows与客户端进行通信时，该怎么办？ MS应该花一些时间来完善其工具集以进行JavaScript调试，甚至可能在MSDN上提供有关JSON / JQuery的系列文章。只是一些想法。

我认为MVC将在企业级应用程序中获得更大的发展，与小型妈妈和流行应用程序相比，可测试性和灵活性更为重要。

目前尚无计划逐步淘汰经典的代码隐藏模型，而且我认为，由于大多数人已经习惯了该技术，因此许多人很可能会继续使用它。

如果没有MVC经验，那么这可能是一个范式转变。我看不到有成群的人涌向它。我认为80％的代码隐藏和20％的MVC百分比将是正确的。

由于代码隐藏模型已经存在了很长时间，因此我敢打赌，有很多程序员只有经典的代码隐藏事件生命周期经验。

我们应该仔细研究ASP.NET MVC的5个理由

MVC真正有意义的地方是我们是否已经了解HTTP和Rest的基本概念。如果我们确实想利用自定义JavaScript并拥有高度域用户优化的体验。如果我们喜欢通过所有拖放控件进行Web表单开发，并且对用户体验和Atlas更新面板感到满意，那么就应该坚持使用它。

MVC适用于希望轻松利用.NET服务器端和自定义客户端的其他人。它适合那些拥有Web设计师和想要构建自定义HTML的人们，以及那些有成就的程序员。

如果我们是一个孤立的人(也许是IT人士)，将一些东西扔到办公室的Intranet上，则Webforms可能会更好。这就是webforms和.NET真正发挥作用的地方。一些较新的工具EF和MVC对团队和更大规模的开发具有广告价值。

所以不，我认为它们是相辅相成的。