ASP.NET MVC、MVP、MVVM的比较与区别总结(一)

MVC、MVC和MVVM都是用来解决界面呈现和逻辑代码分离的问题。他们以前只知道一部分，但没有深入研究，他们也不知道一些概念和差异。现在，在核对数据的同时，结合自己的理解，谈谈对这三种模式的理解及其区别。欢迎大家拍砖。阅读目录：复制代码如下：一、MVC、MVP、MVVM诞生的要求？2.典型的耦合码3。MVC模式3.1 MVC框架中的主动MVC 3.2被动MVC 3.3 Web应用3.4 MVC总结1。MVC、MVP、MVVM诞生的要求？软件的核心和基础是什么？是的，是数据。我们写的所有代码都围绕着数据。围绕数据生成和修改的变化，出现了业务逻辑。围绕数据的显示，出现了不同的接口技术。没有设计良好的代码，数据层(持久层)、业务逻辑层和接口代码往往是耦合的。ORM和其他框架解耦了业务逻辑和数据之间的耦合，业务逻辑不再关心底层数据是如何存储和读取的。呈现给业务逻辑层的所有数据都是对象。而MVC、MVC、MMVM则用来解决业务逻辑和视图之间的耦合。第二，一个典型的耦合代码复制代码如下： { sqldata adapter=new sqldata adapter(' select * from table 1 '，' server=。数据库=dbuid=sapwd=password ')；数据集ds=新数据集(' DS1 ')；适配器。填充(ds)；这个。GridView1 .数据源=ds这个。GridView 1 . DataBind()；}上述代码包含数据访问和页面显示。当项目的复杂性较高时，这种代码将变得非常难以维护，层次结构也不清晰。MVC模式的全称是模型视图控制器，是模型-视图-控制器的简称。MVC最初存在于桌面程序中，m指的是业务模型，v指的是用户界面，c指的是控制器。使用MVC的目的是将m和v的实现代码分开，使同一个程序可以使用不同的表达形式。3.1主动MVC的理论对应主动MVC，这里的主动意味着模型会主动通知View更新。但是，我们使用的是MVC框架、Struts、ASP.NET MVC等。它们不是活动的MVC(所有视图都通过控制器更新)。模型用于封装与应用程序的业务逻辑和数据处理方法相关的数据。模型中数据的变化通常通过刷新机制来宣布。为了实现这个机制，用于监控这个模型的视图必须提前注册在这个模型上，这样视图就可以知道数据模型中的变化。视图层负责数据呈现。这种观点通常没有程序逻辑。为了实现视图上的刷新功能，视图需要访问它监控的数据Model，所以它应该提前从它监控的数据订阅Model的事件。控制器是m和v之间的连接器，用于控制应用程序的流程。它处理事件并做出响应。“事件”包括用户行为和数据模型中的变化。

3.2被动MVC下图展示了被动MVC中的流程。与活动MVC不同，View不订阅Model的数据更改事件，而是等待Model通知View需要根据新数据进行更新。在被动MVC中，控制器负责通知视图有数据变化，需要更新视图。

被动MVC与主动MVC的区别在于：1。模型对视图和控制器一无所知，但它只被它们使用；2.控制器使用视图，并通知它更新数据显示。3.只有当控制器通知视图从模型中获取数据时，视图才会这样做(视图不会订阅或监控模型的更新)。3.web应用中的MVC框架是被动的MVC模式，因为http是基于Web应用中的请求和响应协同工作的，所以当服务器端的模型(数据)发生变化时，它不会立即更新客户端的视图，而只是在客户端重新请求或刷新页面时才会更新。下图展示了一个典型的MVC框架中MVC的请求过程。

3.4 MVC总结了MVC的优点由于MVC很好地将视图层和业务层分开，所以它具有以下优点：耦合性低，开发速度快，可维护性高，没有控件的概念，没有html的封装，易于理解，更类似于其他平台(java、php)。让人才容易获得MVC的错误。1.将模型理解为实体，模型在MVC中应该包含两个功能，一个是处理业务逻辑，另一个是提供视图显示的数据。2.将所有业务逻辑放在控制器上，本质上是由于对模型的影响不明确。模型在MVC架构中起着重要的作用，它应该是业务逻辑真正的实现层。因此，模型实际上是一个商业模型。但是，控制器只充当“桥梁”，负责将视图的请求转发给模型，然后通知视图模型处理的完成。控制器是用来解耦视图和模型的，具体来说就是把UI和逻辑(接口和代码)分开。从http://www.techopedia.com/definition/27454/model-mvc-aspnet复制的代码如下： Techo儿科解释模型(MVC)。模型是实现领域逻辑的MVC的一部分。简单来说，这个逻辑用于处理数据库和用户界面之间传递的数据。该模型被称为域对象或域实体。域对象存储在ASP.NET的“模型”文件夹下。域模型代表要处理的数据的应用程序视角，而视图模型是生成视图的引擎所必需的。这个定义是在ASP的上下文中写的。net.mvc的缺点，完美的mvc应用场景应该是这样的：有一个Student Model，它与StudentListView和student editview相关联。学生模型提供学生的采集数据以显示学生列表视图对于学生编辑视图，学生模型提供单个学生数据以显示学生编辑视图并响应学生编辑视图的保存操作。但这只是一种完美的情况。在实际应用中，不仅学生的信息显示在列表视图上，还可能需要学生的历史成就、家庭情况和教师信息。这些不是学生模型提供的。也许我们可以扩展学生模型，扩展学生模型可以提供的信息，包括成绩信息等。这本身也是可以的。但是，如果学生显示视图，这个需要只需要额外的成绩信息，另一个视图只需要额外的家庭信息，学生模型是不是有点累，你可以知道需要多少个不同的视图？让逻辑端代码不断修改以适应视图端，好吗？由于MVC的设计思想是基于模型的，没有考虑视图的复杂性，由此带来的问题是模型很难满足视图复杂多变的变化。相比之下，MVP和MVVM要好得多。它们独立于演示者和视图模型，以对应于每个视图。