我见过ASP.NET社区关于MVC的嗡嗡声。我知道它的起源基础知识，并且基于ASP.NET MVC有很多网站（除非我错了，堆栈溢出本身）。MVC ||的实际应用何时使用或不使用MVC
从我听过和关于MVC的所有内容看来，它似乎是ASP.NET开发的未来。但是因为我通常不会涉足.NET Web开发，所以我还想知道以下几点：什么时候适合使用MVC，什么时候不使用，为什么？ MVC的巨大（和可怕的）使用的例子会很有趣。
虽然我意识到还有其他MVC实现查看RoR等其他语言，但我更感兴趣的是它对.NET程序员的影响。
如果这已经过去了，我的道歉！
这是我的2美分关于MVC的Web应用程序。对于MVC最初设计的那种GUI应用程序，需要“侦听器”代码，以便在事件更改模型数据时可以更新UI。
在Web上的MVC中，这是不必要的，您可以免费获得您的监听器：Web服务器和HTTP请求是事件。所以真正的网页MVC应该更简单。事实上，它可以归结为Mediator模式，Controller在模型和视图之间进行中介。
有两件事情有很多困惑。无论传统的“智慧”：
框架= MVC
数据库数据=“模型”
“全栈” Web开发框架通常会添加大量功能，并可能会或可能不会是MVC！以他们的核心为导向。许多框架添加的功能之一是数据库访问或对象关系映射功能，并且由于框架和MVC会感到困惑，随后数据库数据和MVC的模型面也会变得混乱。通常可以将该模型视为应用程序的基础数据，但它不一定来自数据库。一个很好的例子可能是wiki，其中底层模型/数据由文件修订数据组成，例如来自RCS。
希望这可以帮助，我相信别人会有很多补充。
ASP.NET MVC不是ASP.NET开发的未来，它只是一种开发ASP.NET网站的新方法。微软已经明确表示，他们将来会继续支持和改进WebForms和MVC。
我想不出任何网站，是不是适合使用MVC。你也可以为WebForms争辩。
无论你选择哪一个都是个人选择，并且取决于开发团队的经验和偏好。
在几个大项目中使用MVC后，我个人绝不会回到WebForms开发。在我看来，WebForms通过http和html放置了一个不必要的抽象层。对于快速原型，您可以使用WebForms更快地获得拼凑起来的东西，但在此之后，抽象的复杂化使事情变得更加困难而不是简单。在我看来，使用WebForms的唯一令人信服的理由是当前可用的第三方控件的丰富级别。但是你可以混合使用WebForms和MVC，所以它很容易获得两全其美。
我在一家同时拥有ASP.NET和MVC应用程序的商店工作。我认为最初我偏向于网络形式，因为我与他们合作了几年，但在完成一些MVC项目之后，我更喜欢它。
然而，需要考虑的是，如果您有一个经验丰富的Web表单开发人员团队，由于学习曲线的原因，MVC应用程序中的初始进度将会变慢，因此如果项目的时间表非常紧凑，不是转换的最佳时机。
除此之外，我想不出任何情况下，我更喜欢网页形式超过MVC在这一点上。
根据我自己的经验，我可以告诉你，如果你没有任何Winforms或Webforms背景，你可能会觉得在MVC下更加舒适，因为你并不是“期望”ASP.NET Webforms中的任何东西世界。另一方面，作为建议，我鼓励您查看其他MVC框架，比如Django或RoR，它们在MVC思维方式上更“成熟”。我对ASP.NET MVC感到满意，但看看其他解决方案可以帮助您更好地理解框架背后的范例。
我会说一个非常引人注目的使用MVC的场景是，如果你有一群经验丰富的.NET开发人员不有WebForms的经验。
我自己从这种情况出发（很少有网络体验）我发现它在WebForms上使用MVC的效率和舒适度要高得多。
由于前面提到的抽象，我发现很难提取WebForms - （我认为WebForms复杂性的证明是我从来没有遇到过任何人，我会认为WebForms“专家”即知道页面生命周期的心脏/数据绑定回到前端等）。
使用MVC实际上允许我使用我的.NET和软件体验，而无需大量投资学习WebForms框架。不仅如此，我对HTTP有了更好的理解，而且我认为这将允许更高质量的解决方案。
恕我直言，MVC允许你比WebForms更好地分解代码，所以我认为有很多“模式”体验的开发人员在MVC中会更加舒适。
只需添加ASP.NET MVC是模型不可知的。该模型只是一个对象或集合，而在其他MVC框架（如RoR）中，则在此情况下提供模型基础实现，即ActiveRecord模式。 – 2009-04-21 13:30:42
Upvoted的笔记说，MVC不是一个框架，并且该模型不是数据库！ – 2009-04-21 13:49:57