什么是MVC，它有什么优势？

我发现什么是MVP和MVC和有什么区别，但它并没有真正回答这个问题。

我最近开始使用MVC，因为它是我和我的工作伙伴将要使用的框架的一部分。因为看起来容易，并且从显示分离了的过程所以选了，除了这个以外，有不知道什么可以遗漏吗？

优点

显示和处理是分开的

缺点

目前还没有

MVC是模式，视图和控制器的分离 – 仅此而已。这只是一个范例; 在devise课程时，你应该有一个理想的想法。避免将三个类别的代码混合到一个类中。

例如，当一个表格网格视图显然应该显示一次数据，它不应该有从哪里检索数据的代码，或者它的本地结构（模型）是什么样的。同样，虽然它可能具有总结列的function，但实际的总和应该在控制器中发生。

一个“保存文件”对话框（视图）最终将用户选取的path传递给控制器 ， 控制器然后向数据模型询问数据，并进行实际的保存。

这种责任的分离使得路上的灵活性变得可行。例如，因为视图不关心底层模型，所以支持多种文件格式更容易：只需为每个文件添加一个模型子类。

分离的担忧是biggy。

能够取笑这些组件使得代码更易于重复使用和独立testing。如果您实际上不知道MVC是什么，请注意尝试了解人们的意见，因为仍然存在关于“模型”的争论（无论是业务对象/ DataSets / DataTables还是代表底层服务层）。

我已经看到各种各样的自称为MVC的实现，但并不完全如Jeff的文章中的评论所示，MVC是一个有争议的观点，我不认为开发人员会完全同意。

所有不同的MVCtypes都可以在这里find 。

杰夫有一个关于它的post ，否则我在苹果的网站上find一些有用的文件，在cocoa教程（例如这个）。

我认为使用MVC模式的另一个好处是它为devise的其他方法打开了大门，例如MVP / Presenter以及许多其他MV *模式。

如果没有devise“组件”的基本分离，采用这些技术将会困难得多。

我认为这有助于使代码更加基于接口。不仅在单个项目中，而且几乎可以开始开发通用的“视图”，这意味着您可以在应用程序中使用更多的“grunt”代码。例如，一个非常抽象的“数据视图”，它只需要一堆数据并将其引发到一个通用的网格布局。

编辑：

如果我没有记错的话，这是MV *模式上的一个不错的播客（听了不久前！）

我可以想到的一个问题是，如果您需要在视图中真正快速访问数据（例如，像骨位置这样的游戏animation数据）。在这种情况下保留一个分隔层是非常低效的。

否则，对于大多数数据驱动而不是graphics驱动的其他应用程序来说，这似乎是驱动用户界面的合理方法。

如果你按照stackoverflow的播客，你可以听到杰夫（和杰夫？）讨论它的伟大。 http://blog.stackoverflow.com/2008/08/podcast-17/ 。但请记住，使用这些单独的图层意味着未来的事情会变得更加容易 – 现在更困难了。而层可以让事情变慢。而你可能不需要它们。但是，不要让它阻止你学习它是什么 – 在构build大型，强大，长寿系统时，这是非常宝贵的。

它分离了由控制器控制的模型和视图，就模型而言，模型必须遵循面向对象的体系结构，未来的增强和代码库的其他维护应该非常容易，代码库应该是可重用的。

相同的模型可以有任何的意见例如）相同的信息可以显示在不同的graphics视图。相同的观点可以有不同的模型，例如）不同的细节可以显示为一个单一的graphics，如条形图。这就是View和Model的可重用性。

视图的增强和对构build视图的新技术的其他支持可以轻松实现。

从事视图工作的人不需要了解底层的模型代码库和架构，反之亦然。

这里没有提到的MVC的主要优点之一是MVC提供了可以启用SEO的RESTful URL。当您明智地命名您的控制器和操作时，如果search引擎只查看您的网站Url，就可以更轻松地find您的网站。例如，你有一个汽车销售网站和一个页面，显示兰博基尼威尼诺汽车，而不是有http://www.MyCarSale.com/product/6548指的页面，您可以selecthttp://www.MyCarSale.com/SportCar/Lamborghini-VenenourlSEO的目的。

这是一个很好的答案，MVC的优势，这里是一篇文章如何创build一个SEO友好的url。

MVC架构的主要优点是区分模型，视图和控制器中项目的层次以实现代码的可重用性，易于维护代码和维护。最好的事情是开发人员感觉很好，在项目维护之间添加一些代码。

在这里你可以看到MVC架构的主要优点。

！[mvc架构] [1]

模型 – 视图 – 控制器（MVC）是实现用户界面的软件架构模式。它将给定的软件应用程序划分为三个相互关联的部分，以便将信息的内部表示与信息呈现给用户或从用户接受的方式分开。

MVC只是一种通用devise模式，在精益Web应用程序开发的背景下，开发人员可以轻松地将HTML标记保存在应用程序的表示层（视图）中，以便与接收和处理客户端请求的方法控制器）以及视图（模型）中返回的数据表示。所有关于问题的分离都是关于分离的，也就是说，保持代码服务于一个function目的（例如，处理客户端请求）的代码被完全不同的function目的（例如表示数据）所隔离。

为什么花费超过5分钟的时间试图构build一个网站的人可能会意识到需要将HTML标记，JavaScript和CSS保存在单独的文件中：如果只是将所有代码转储到单个文件中，最终得到的意大利面几乎是不可修改的。

既然你问了可能的“缺点”：我不是软件架构devise方面的权威人士，但是基于我在MVC中开发的经验，我认为指出遵循一个严格的，简洁的MVCdevise模式是最有用的为1）轻量级的networking应用程序，或2）作为一个较大的企业应用程序的UI层。我很惊讶这个规范没有提到更多，因为MVC没有包含你的业务逻辑，领域模型或者你的应用的数据访问层中的任何东西的明确定义。当我开始在ASP.NET MVC中开发时（即，在我知道其他软件架构甚至存在之前），我将最终得到非常臃肿的控制器甚至视图模型，充满了业务逻辑，如果我一直在研究企业应用程序，使其他不熟悉我的代码的开发者很难修改（即更多的意大利面条）。