MVC的实际应用||何时使用，或不使用MVC

Question

我看过ASP.NET社区对MVC的嗡嗡声。我知道它的起源的基础知识，并且有很多站点（除非我错了，堆栈溢出本身）基于ASP.NET MVC。

从我听过的所有关于MVC的内容中可以看出，它似乎是ASP.NET开发的未来。但由于我通常不会涉及.NET Web开发，所以我想知道以下内容：何时使用MVC是合适的，什么时候不适用，为什么？ MVC的伟大（和可怕）使用的例子将是令人着迷的 虽然我意识到MVC的其他实现还有其他语言如RoR，但我对它对.NET程序员的影响更感兴趣。

如果这已经过去了，我道歉！

Answer 1

以下是关于Web应用程序MVC的2美分。对于最初用于MVC的GUI应用程序，需要“侦听器”代码，以便在事件更改模型数据时更新UI。

在MVC for web中这是不必要的，您可以免费获得监听器：Web服务器，HTTP请求就是事件。所以真正的网络MVC应该更简单。实际上，它可以归结为Mediator模式，Controller在模型和视图之间进行调解。

有两件事情存在很多困惑。无论传统的“智慧”如何：

框架！= MVC

数据库数据！=“模型”

“完整堆栈”Web开发框架通常会添加许多功能，并且可能会或可能不会以MVC为导向。许多框架添加的功能之一是数据库访问或对象关系映射功能，并且由于框架和MVC混淆，随后数据库数据和MVC的模型方面也会混淆。通常可以将模型视为应用程序的基础数据，但它不必来自数据库。一个很好的例子可能是维基，其中底层模型/数据由文件修订数据组成，例如，来自RCS。

希望这会有所帮助，我相信其他人会有很多补充。

Answer 2

我想说一个非常引人注目的使用MVC的方案是，如果你有一群经验丰富的.NET开发人员不有WebForms的经验。

自己来自这种情况（很少的网络体验）我发现使用MVC而不是WebForms我更有效率和舒适。

由于前面提到的抽象，我发现拾取WebForms非常困难 - （我认为WebForms复杂性的证据是我从来没有见过任何我认为是WebForms“guru”的人，即知道页面生命周期的关键/数据绑定从前到后等。）。

使用MVC实际上允许我使用我的.NET和软件体验，而无需大量投资学习WebForms框架。不仅如此，我对HTTP有了更好的理解，我认为这将允许更高质量的解决方案。

IMHO MVC允许您比WebForms更好地考虑代码，因此我认为具有大量“模式”体验的开发人员在MVC中会更加舒适。

Answer 3

ASP.NET MVC不是ASP.NET开发的未来，它只是一种用ASP.NET开发网站的新方法。微软明确表示他们将来会继续支持和改进WebForms和MVC。

我想不出任何网站，如果使用MVC是不合适的。您也可以为WebForms争论相同。

您是否选择其中一个是个人选择，并且取决于开发团队的经验和偏好。

在几个大项目中使用MVC之后，我个人永远不会回到WebForms开发。在我看来，WebForms在http和html上放置了一个不必要的抽象层。对于快速原型，您可以使用WebForms更快地将拼凑在一起的东西拼凑在一起，但在此之后，抽象的复杂性使事情变得更难而不是更容易。在我看来，使用WebForms的唯一令人信服的理由是当前可用的第三方控件的丰富级别。但是你可以混合使用WebForms和MVC，因此它很容易实现两全其美。

Answer 4

我在一家同时拥有ASP.NET和MVC应用程序的商店工作。我认为最初我偏向于网络表单，因为我与他们合作了好几年，但在完成一些MVC项目之后，我更喜欢它。

然而，需要考虑的是，如果你有一个经验丰富的Web表单开发团队，由于学习曲线，MVC应用程序的初始进度会慢一些，所以如果项目的时间表非常紧，那么可能不会是过渡的最佳时机。

除此之外，我无法想到在此时我更喜欢使用网络表单而不是MVC的情况。

Answer 5

根据我自己的经验，我可以告诉你，如果你没有任何Winforms或Webforms背景，你可能会觉得在MVC保护伞下更舒服，因为你并没有“期待”来自ASP.NET Webforms世界的任何东西

另一方面，作为推荐，我建议您查看其他MVC框架，如Django或RoR，这些框架在MVC思维方式上更为成熟。我对ASP.NET MVC感到满意，但是寻找其他解决方案可以帮助您更好地理解框架背后的范例。