Android之MVC、MVP、MVVM
本文将详细阐述以下mvc、mvp、mvvm三种理念的定义
mvc
mvc全名是model view controller,是软件工程中的一种软件架构模式,把软件系统分为三个 基本部分:模型(model)、视图(view)和控制器(controller)。
- model(模型)是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。模型表示企业数据和业务规则。在mvc的三个部件中,模型拥有最多的处理任务。例如它可能用像ejbs和coldfusion components这样的构件对象来处理数据库,被模型返回的数据是中立的,就是说模型与数据格式无关,这样一个模型能为多个视图提供数据,由于应用于模型的代码只需写一次就可以被多个视图重用,所以减少了代码的重复性。
- view(视图)是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。视图是用户看到并与之交互的界面。mvc好处是它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生,不管这些数据是联机存储的还是一个雇员列表,作为视图来讲,它只是作为一种输出数据并允许用户操纵的方式。
- controller(控制器)是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据,控制用户输入,并向模型发送数据。控制器接受用户的输入并调用模型和视图去完成用户的需求,所以当单击web页面中的超链接和发送html表单时,控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求,然后再确定用哪个视图来显示返回的数据。
mvc是一种软件设计典范,用一种业务逻辑和数据显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在界面和用户围绕数据的交互能被改进和个性化定制的同时而不需要重新编写业务逻辑。
mvc特点:
mvc模式的特点在于实现关注点分离,即应用程序中的数据模型与业务和展示逻辑解耦。在客户端web开发中,就是将模型(m-数据、操作数据)、视图(v-显示数据的html元素)之间实现代码分离,松散耦合,使之成为一个更容易开发、维护和测试的客户端应用程序。
view 传送指令到 controller ;
controller 完成业务逻辑后,要求 model 改变状态 ;
model 将新的数据发送到 view,用户得到反馈。
mvc流程:
mvc流程一共有两种,在日常开发中都会使用到。
一种是通过 view 接受指令,传递给 controller,然后对模型进行修改或者查找底层数据,最后把改动渲染在视图上。
另一种是通过controller接受指令,传给controller:
mvc优点:
- 耦合性低,视图层和业务层分离,这样就允许更改视图层代码而不用重新编译模型和控制器代码。
- 重用性高
- 生命周期成本低
- mvc使开发和维护用户接口的技术含量降低
- 可维护性高,分离视图层和业务逻辑层也使得web应用更易于维护和修改
- 部署快
mvc缺点:
- 不适合小型,中等规模的应用程序,花费大量时间将mvc应用到规模并不是很大的应用程序通常会得不偿失。
- 视图与控制器间过于紧密连接,视图与控制器是相互分离,但却是联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用。
- 视图对模型数据的低效率访问,依据模型操作接口的不同,视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问,也将损害操作性能。
mvc应用:
在web app 流行之初, mvc 就应用在了java(struts2)和c#(asp.net)服务端应用中,后来在客户端应用程序中,基于mvc模式,angularjs应运而生。
mvp
mvp(model-view-presenter)是mvc的改良模式,由ibm的子公司taligent提出。和mvc的相同之处在于:presenter负责业务逻辑,model管理数据,view负责显示,同时改变了通信方向。
mvp特点:
- m、v、p之间双向通信。
- view 与 model 不通信,都通过 presenter 传递。presenter完全把model和view进行了分离,主要的程序逻辑在presenter里实现。
- view 非常薄,不部署任何业务逻辑,称为”被动视图”(passive view),即没有任何主动性,而 presenter非常厚,所有逻辑都部署在那里。
- presenter与具体的view是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更view时候可以保持presenter的不变,这样就可以重用。不仅如此,还可以编写测试用的view,模拟用户的各种操作,从而实现对presenter的测试–从而不需要使用自动化的测试工具。
mvp优点:
- 模型与视图完全分离,我们可以修改视图而不影响模型;
- 可以更高效地使用模型,因为所有的交互都发生在一个地方——presenter内部;
- 我们可以将一个presenter用于多个视图,而不需要改变presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁;
- 如果我们把逻辑放在presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试)。
mvp缺点:
视图和presenter的交互会过于频繁,使得他们的联系过于紧密。也就是说,一旦视图变更了,presenter也要变更。
mvp应用:
可应用与android开发。
mvvm
mvvm是model-view-viewmodel的简写。微软的wpf(windows presentation foundation–微软推出的基于windows 的用户界面框架)带来了新的技术体验, 使得软件ui层更加细节化、可定制化。与此同时,在技术层面,wpf也带来了 诸如binding(绑定)、dependency property(依赖属性)、routed events(路由事件)、command(命令)、datatemplate(数据模板)、controltemplate(控制模板)等新特性。mvvm模式其实是mv模式与wpf结合的应用方式时发展演变过来的一种新型架构模式。它立足于原有mvp框架并且把wpf的新特性糅合进去,以应对客户日益复杂的需求变化。
mvvm优点:
mvvm模式和mvc模式类似,主要目的是分离视图(view)和模型(model),有几大优点:
- 低耦合,视图(view)可以独立于model变化和修改,一个viewmodel可以绑定到不同的”view”上,当view变化的时候model可以不变,当model变化的时候view也可以不变。
- 可重用性,可以把一些视图逻辑放在一个viewmodel里面,让很多view重用这段视图逻辑。
- 独立开发,开发人员可以专注于业务逻辑和数据的开发(viewmodel),设计人员可以专注于页面设计,使用expression blend可以很容易设计界面并生成xml代码。
- 可测试,界面向来是比较难于测试的,而现在测试可以针对viewmodel来写。
下一篇: C语言实现简单的三子棋游戏源码