什么是MVC,它有什么优势?

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

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

优点

  1. 显示和处理是分开的

缺点

  1. 目前还没有

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中开发时(即,在我知道其他软件架构甚至存在之前),我将最终得到非常臃肿的控制器甚至视图模型,充满了业务逻辑,如果我一直在研究企业应用程序,使其他不熟悉我的代码的开发者很难修改(即更多的意大利面条)。

Interesting Posts