假设您明天将启动一个新的ASP.NET网站/应用程序。你会选择Web窗体还是MVC，为什么？
MVC宝贝！还有JQuery！
编辑：好吧，可以公平地说，我的回应需要更多的信息。
我选择MVC的原因如下：
我之所以选择MVC，仅仅是因为它被设计成可测试和可模拟的。这将是我做出决定的主要因素。
WebForms对单元测试来说要困难得多，因为它们重新植根于几个具体的类中，而这些类对Mock来说是很困难的。其中包括HttpContext、HttpResponse、HttpRequest和HttpCookie。
MVC设计为可测试的，它的API极大地促进了这一点。
关于MVC可测试性的好文章：http://dotnetslackers.com/articles/aspnet/ASPNETMVCFrameworkPart2.aspx
就我个人而言，我决定同时使用。。。
If it s a website (viewed online), I have decided to use ASP.NET MVC. If it was an application (web application with a single purpose) I have decided to use web forms.
这个决定完全基于案例使用和您试图提供的解决方案。如果你对好的SEO和更快的网站感兴趣，MVC是比web表单更干净、更快的HTML。
然而，如果您在同一页面上使用了大量过滤器、网格和回发的复杂功能，并且您在Web窗体方面经验丰富，那么就坚持使用它。
如果我从今天开始，我可能仍然会坚持使用网络表单，因为它有大量的知识和资源。
也就是说，我真的很想尝试一下MVC，正如其他人所提到的，社区内的兴奋意味着很快就会有很多人支持它。
MVC FTW！，原因？
MVC是“一天的味道”，还是它有持久力？
我曾经使用过MVC，并且拥有大量的网络表单经验。我经常想知道MVC的持久力。
在选择其中一个时，你应该考虑到这一点。您希望在整个产品寿命内支持什么？
如果我还没有尝试MVC，我不能说我真的会选择哪一个。但我会有点担心把它用于一个真正的大型企业项目。
滚动浏览pass questions，你会发现MVC有很多问题（与好的o WebForms相比）。仅此一点就让我很担心。很多问题似乎都是针对用户界面的特殊需求提出的。同样，由于没有尝试过，我还不知道它有多成熟，但我仍然有点担心。
也许曾经在企业项目中使用过它的人可以透露一些信息。
虽然MVC是一个新生事物，但使用Web窗体模型进行设计仍然有很多好处。
Rachel Appel did a great presentation at MIX on this very topic. You can view the video here:
Choosing between ASP.NET Web Forms and MVC
http://videos.visitmix.com/MIX09/T23F
我会为本地/内联网应用程序选择Webforms，为公共/互联网站点（博客/论坛/演示文稿/简单服务）选择MVC。“WebForms应用程序模型”在丰富的州支持至关重要的领域更可取
一周前，我为自己的产品创建了一个新网站，我对ASP.NET MVC非常满意。一切看起来都很自然，如果有些东西不起作用或看起来不像我想要的那样，我总是知道该去哪里看。
坦率地说，我花在CSS上的时间最多。编码，与jQuery集成。。。花生。
OTOH，如果你不是经验丰富的开发人员，ASP.NET将不会对你有吸引力，因为它鼓励你全力以赴，控制网站的各个方面-HTML标记、CSS等，这反过来意味着没有控件、拖放视觉编辑等。
与传统的ASP.NET不同，在传统的ASP.NET中，你只能自己处理，最终往往会在不同的页面中混合各种UI、持久性（DB）和业务逻辑代码，MVC将为你提供指导，并帮助你更一致地构建应用程序。如果你不喜欢“固执己见”的框架和/或只想在不关心网站结构、可维护性、可扩展性等的情况下完成工作，你就不会有这种想法。
请注意，如果您所构建的只是一个一次性的intranet站点，那么完全有可能不关心这一点，但对于公共Internet站点，我每次都会选择MVC而不是经典的ASP.NET。
MVC模式
……很明显，这就是未来
In ASP.NET MVC you sacrifice your controls toolbox, URL routing is already in ASP.NET (web forms)
所以我会坚持使用ASP.NET web表单（我并不是说MVC不好。）
jQuery，你认为IT人员会让你使用它吗？
ASP.NET MVC，因为我想学习如何使用它。
我目前选择ASP.NET MVC有两个原因：1）我想学会掌握它。2）围绕ASP.NET MVC已经形成了一个很好的社区，每个人似乎都对它的使用持积极态度。我迫不及待地想看看这一切的结局，我想成为其中的一员。
我想使用MVC。当我使用WebForms时，我总是在与抽象作斗争。
要有效地使用WebForms，实际上你需要比使用PHP之类的东西更多地了解网络是如何工作的。我发现自己在使用<；asp:文字而不是<；asp:标记以避免放置<；span>围绕文本和运行实验室来确定事件的顺序，等等。
这真的取决于项目，因为我没有用MVC构建任何东西，如果项目的交付时间很短，我可能会发现MVC中的一些障碍，这可能会使我无法及时交付项目。
I wait for MVC on .net for a long time. I think more than 90% people will choose MVC rather than webform.
如果这是一个个人项目，那么我会使用MVC。只是想了解更多信息。如果这是一个正在进行的项目，我会使用WebForms，可能会与DynamicData结合用于管理部分。原因是使用我所知道的技术会更有效率，而使用DynamicData作为管理部分可以让我在几分钟内设置该部分。
一如既往，这取决于您正在开发的应用程序类型和个人情况。我们的许多内部应用程序都是在SharePoint中开发的，因为SharePoint是我们内部网类型应用程序的首选平台。
这自动将我们限制在标准模型上的ASP.Net。
我真的很想掌握MVC，但我在工作中没有理由这样做，而且我有两个孩子和一个妻子在家，所以没有时间在家发展。
有时情况会迫使你出手，只要我们都能选择使用什么平台、框架等进行开发就好了。
我目前正在使用jQuery和jQueryui在Asp.netMVC中进行一个项目，这很有趣。
如果您熟悉html和javascript（或rails等其他MVC框架），那么MVC比旧的web表单更有意义。您可以控制输出，而不是表单上的模糊控件，因此，如果页面上有错误或您想更改布局，您可以：）。
MVC模式。我们将重做一个SEO密集型和MVC接缝的应用程序，以便开箱即用。另外，我想和操场上那些很酷的孩子们一起玩。
我刚刚在MVC平台上发布了一个主要的公共网站，之前的所有项目都使用了网络表单。毫无疑问，这是要走的路，国际海事组织。
对于网络表单，我发现随着时间的推移，网站往往会变得一团糟，因为代码后面有处理视图逻辑和控制器逻辑的代码块。随着网站的发展和逻辑变得越来越复杂，很难追踪发生了什么以及在哪里。
我发现MVC迫使你以一种更合乎逻辑的方式来分解事物。控制器和模型类使您能够更好地控制应用程序的组织。此外，视图更灵活，因为有一种特定的方式可以通过模型向它们提供数据。
此外，正如其他人提到的那样，您可以对标记和url进行更多的控制，而且它与mvc等客户端库的配合也更好。
我唯一会使用MVC的时候是，如果我正在构建一个专注于报告某种数据的intranet站点，那么asp.net附带的内置控件可以节省开发时间，而我不那么关心外观。我再也不会在面向公众的大型网站上使用asp.net网页表单了。
二者都
我正在做MVC的长期工作。我有太多的代码可以很容易地在Web窗体中工作。MVC是梦幻般的，但它在富有成效的领域留下了很多东西，如模板化网格和列表、基本的UI控件（日历、自动完成等）和scafolding。这些都是Web Forms擅长的领域，但如果您想要精确的控制并保持简单，则会偏离轨道。
如果MVC 3和EF Code Only愿意弥合两者之间的差距，那么它们可能是一场伟大的婚姻。大多数使用Ruby的人都将其用于Rails，而ActiveRecord使其易于使用。
此外，我很想看到一个支持MS的MVC并行“功能包”项目，类似于他们开发Microsoft Ajax Toolkit的方式，也就是说每季度更新一次。我发现MVC Futures和MVCContrib都缺乏。但我知道他们只有这么多预算。所以，希望MVC 3能改变这一切。
如果您正在为Intranet开发，只需对ASP.NET MVC说“不”即可。当然是互联网。
嗯。现在我和你一样困惑，即将开始建设一个新网站：）。我本来打算从Webforms开始，但现在我看到了人群的方向，我想我现在要试试MVC了。
谢谢你问这个问题。
现在它已经RTMed了，而且上面有一些非常好的资源，我会说ASP.net MVC将是我的强烈偏好，但它并不是一成不变的。
尽管Web表单还没有消失，它仍然存在，它仍然受到支持，我已经在几个主要网站上工作过，并且非常成功地使用了Web表单，所以如果有其他外部因素，比如客户偏好，或者可能有一个拥有扎实Web表单经验的团队，那么我仍然很乐意使用Web表单。也就是说，我已经用MVC做了一个项目（当时它还在预览中），我更喜欢它——我的理由与上面给出的类似，所以我不会重复所有的。我要说的是，如果可测试性不是最好的原因，那么它肯定是最重要的原因：）。
我会选择MVC，因为设计师和开发人员可以在同一个项目上并行工作。设计人员可以处理视图部分（JavaScript、CSS、HTML），而后端开发人员可以处理控制器代码。
我想做ASP.Net MVC，尽管我对MVC还很陌生。但在可预见的未来，情况并非如此。
事实上，在接下来的几周里，我将开始重建一个用ASP.NET 2.0编写的糟糕网站，我将使用ASP.NET MVC。出于许多与上述相同的原因。我宁愿不使用自定义的.NET控件，而自己处理HTML/JavaScript（使用jQuery）。我也做了很多Java web开发，所以对底层HTML/JavaScript/CSS有一个很好的理解对我来说很重要。
