本文目录
- MVC与MVVM区别
- java学mvc框架好些还是mvvm
- 前端的mvvm是什么意思
- mvvm框架是什么 它和其他框架的区别
- mvvm的原理和理解
- 什么是MVVM
- mvvm设计模式和mvc的区别以及优势
- mvvm框架是什么它和其他框架(jquery)的区别是什么哪些场景适合
- mvvm框架和mvc有什么不同
MVC与MVVM区别
1、MVC允许在不改变视图的情况下改变视图对用户输入的响应方式，用户对View的操作交给了Controller处理，在Controller中响应View的事件调用Model的接口对数据进行操作，一旦Model发生变化便通知相关视图进行更新。
MVC模型关注的是Model的不变，所以，在MVC模型里，Model不依赖于View，但是 View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
2、MVVM与MVC最大的区别就是：它实现了View和Model的自动同步，也就是当Model的属性改变时，我们不用再自己手动操作Dom元素，来改变View的显示，而是改变属性后该属性对应View层显示会自动改变。
此外，MVVM另一个重要特性，双向绑定。它更方便你同时维护页面上都依赖于某个字段的N个区域，而不用手动更新它们。
3、MVC模式是MVVM模式的基础，他们的MV即Model，view相同，不同的是MV之间的纽带部分。
java学mvc框架好些还是mvvm
如果项目简单，没什么复杂性，未来改动也不大的话，那就不要用设计模式或者架构方法，只需要将每个模块封装好，方便调用即可，不要为了使用设计模式或架构方法而使用。
对于偏向展示型的app，绝大多数业务逻辑都在后端，app主要功能就是展示数据，交互等，建议使用mvvm。
对于工具类或者需要写很多业务逻辑app，使用mvp或者mvvm都可。
如果想通过一个项目去学习架构和设计模式，建议用MVC然后在此基础上慢慢挖掘改进。最后你可能发现，改进的最终结果可能就变成了mvp，mvvm。
前端的mvvm是什么意思
View一般就是我们平常说的HTML文本的Js模板，里面可以嵌入一些js模板的代码，比如Mustache，比如jstl类似的模板伪代码
ViewModule层里面就是我们对于这个视图区域的一切js可视业务逻辑，举个例子，比如图片走马灯特效，比如表单按钮点击提交，这些自定义事件的注册和处理逻辑都写在ViewModule里面了
Module就更简单了，就是对于纯数据的处理，比如增删改查，与后台CGI做交互
那么什么是MVVM框架呢？？一般他们都是这么做的
1. 定义一串所谓的伪模板代码，例如通过className标注，或者自定义tag的方式，将一段html文本区域给标注声明起来，意思就是喊一嗓子，“喂，兄弟们，这块地方我占了，要拉屎去别处拉去”
2. 通过类似jstl之类lamda表达式，来做js模板，“拜托伙计，天堂有路你不走，非要自己搞一套，你就不能暴露接口让大家用自己的模板语言，比如Mustache或者jtpl吗？”
3. 很傻比的封装一串自己的所谓数据模块组件，与不同类型的数据源做数据传输和适配，一般都不会分层很清晰，加入后台数据字段改了，写框架的都没脑子的，从来不做数据字段的自定义适配（举个例子，原来后台传递的字段是person.userName，现在改成了小写，person.username，你就傻逼的去吧模板再改一下吧，其实要解决这个问题，非常简单，在MVVM层中引入一层DO，领域对象层，Module到DO之间还有一层转换就可以搞定这个问题）
4. 非不暴露自己的自定义事件模型，就是那个观察者模式啦，自己乱七八招在页面上绑定一堆form change之类的事件，以实现View与Module的单向绑定
5. 所谓的双向绑定，也就是OOP语言中早被烂透了的getter，setter模型，ES5+可以用defineProperty，低版本就需要自己在js object赋值的时间做写死代码方式的处理了
mvvm框架是什么 它和其他框架的区别
在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 MVC模型关注的是Model的不变，所以，在MVC模型里，Model不依赖于View，但是 View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。 MVVM在概念上是真正将页面与数据逻辑分离的模式，它把数据绑定工作放到一个JS里去实现，而这个JS文件的主要功能是完成数据的绑定，即把model绑定到UI的元素上。 有人做过测试：使用Angular（MVVM）代替Backbone（MVC）来开发，代码可以减少一半。 此外，MVVM另一个重要特性，双向绑定。它更方便你同时维护页面上都依赖于某个字段的N个区域，而不用手动更新它们。
mvvm的原理和理解
MVVM是Model-View-ViewModel的简写。视图模型mvvm模式的核心，它是连接view和model的桥梁。模型指的是后端传递的数据。视图指的是所看到的页面。它有两个方向：一是将【模型】转化成【视图】，即将后端传递的数据转化成所看到的页面。实现的方式是：数据绑定。二是将【视图】转化成【模型】，即将所看到的页面转化成后端的数据。实现的方式是：DOM 事件监听。这两个方向都实现的，我们称之为数据的双向绑定。MVVM的框架下视图和模型是不能直接通信的。它们通过ViewModel来通信，ViewModel通常要实现一个observer观察者，当数据发生变化，ViewModel能够监听到数据的这种变化，然后通知到对应的视图做自动更新，而当用户操作视图，ViewModel也能监听到视图的变化，然后通知数据做改动，这实际上就实现了数据的双向绑定。并且MVVM中的View 和 ViewModel可以互相通信。MVC和MVVM的区别并不是VM完全取代了C，ViewModel存在目的在于抽离Controller中展示的业务逻辑，而不是替代Controller，其它视图操作业务等还是应该放在Controller中实现。也就是说MVVM实现的是业务逻辑组件的重用。由于mvc出现的时间比较早，前端并不那么成熟，很多业务逻辑也是在后端实现，所以前端并没有真正意义上的MVC模式。而我们今天再次提起MVC，是因为大前端的来到，出现了MVVM模式的框架，我们需要了解一下MVVM这种设计模式是如何一步步演变过来的。
什么是MVVM
但其无法与我们的用户进行交互, 所以, 我们需要为其创建一个界面(视图, View), 该视图可以与用户输入设备进行交互, 这很棒, 但问题是如何将View与我们的model关联起来? Binding便可以发挥作用了, 比如视图上的某一个文本框中的文本和Model中的“用户名“关联起来, 用户便可以通过操作该文本框来访问和修改Model的“用户名“了。这是极其简单的情况, 但实际编程时我们发现, Model中的属性(与方法)往往不那么容易与View中的界面控件关联起来, 比如, “类型不匹配“: 界面控件所需要的类型与模型中属性提高的类型不匹配. “需要额外操作“: 模型中的数据需要经过一些额外的处理才能传给视图,反之亦然. 此时, 我们意识到View似乎需要一个“Helper“类来处理一些额外工作.这个helper所包含的代码可以放在除了Model外的很多地方(我们现在不考虑贫血富血之类的争论), 比如View中, 记得自己刚学习窗体程序开发时就是这么干的, 将绝大多数处理逻辑放在那个所谓的CodeBehind中. 后来,正如大家在各种设计模式书籍中所看到的一样,为了将View和Model剥离开来,实现view可替换(比如你可以讲自己精心设计的软件同时运行于窗体程序,Web甚至Mobile上), 便有了MVC. 有了MVC以后似乎就开始滋生M-V-XXX之类的争论与变种模型, 比如MVP以及这里的MVVM,甚至MVP也有着Supervising Controller与Presentation Model两种方式. 但主要围绕两个问题,一是model与view之间的关系, 完全隔离的?单向的还是双向的? 二是这个“XXX“需要完成哪些功能,简单流程调度?复杂规则处理? OK,这些争论都没有关系, 是否采用某种模式取决于你的开发所处的环境(比如语言特性,框架特性)以及你的业务特性以及所面临的主要变化点等等。但与MVC,MVP所不同的是,MVVM的引入不仅仅是技术上的原因(解除耦合应对变化等老生常谈),另外一个很大原因是:软件团队开发方式的改变.如果你做过一段时间的WPF项目开发的话,你可能会有比较明显的感觉:在View层打造上,如何分配程序员和美工的工作.在继续阅读之前,大家可以看看我以前的一篇文章“在UI Designer与Developer之间“. 以前我们团队采用的便是“集成模式“, 我便兼职了其中的“Integrator“角色.这还不错.但说实在的,这仅仅是一个在特殊情况下不得已而为之的暂时方案,所以我们付出了很大的努力开始转向“收割模式“了,要转向这个模式,至少需要两个基本条件:(1)你拥有能够熟练运用Blend等工具能为程序员输出XAML的美工, 他专注于纯粹的UI/UE, 另外他还必须具有一定的“程序员“思维.以便输出的东西能很好地作为程序的一部分而运转起来,而不是仅仅“看上去“是那样的。(2)你需要能够脱离View层但仍能编写出高质量代码的程序员。幸运的是, 我们在努力创造条件1,并取得了很好的效果.(你可以招一个具有Flash脚本编写经验的并且有极大的学习热情的美工人员, 并对他进行Blend的相关培训). 而MVVM模式为我们实现第二个条件提供了极大的便利. 为什么MVC/MVP模式不行而MVVM可以呢? 很简单, 在MVC和MVP模式中, View层都具有很多代码逻辑, 开发View层的是程序员, 虽然UI/UE团队会做很多工作, 但这个层的“实现者“仍然是程序员. 在以前的开发中,其工作得很好, 而在WPF开发中程序员对View层的展现显得力不从心了,美工(指符合上面条件1的美工)虽然很擅长, 但他会说“可惜我不会程序“.于是, 我们需要一种方式将View层的代码逻辑抽取出来,并View层很纯粹以便完全让美工去打造它.相应地, 需要将View层的相应逻辑抽取到一个代码层上,以便让程序员专注在这里。回想一下, 我们只所以要在View(Xaml)背后写一些代码(C#), 无非是想传递一些数据以及传递数据时的数据的处理或在用户与界面控件进行交互时执行一些操作, 最简单的例子是在MVC中当界面发生交互时View去调用Controler中的某个方法, 以便将该操作的相应“指示“传递到“后台“去. 在以前的技术中, 这样的“衔接性“的代码是必须的. 而在WPF中, 则可以通过另外的技术来进行层与层之间的“衔接“, 这就是“Binding“ 和“Command“, 以及稍后我们会提到的“AttachBehavior“. 通过Binding, 我们可以实现数据的传递; 通过Command, 我们可以实现操作的调用.(AttachBehavior的作用稍后再谈). Binding和Command是可以写在XAML中的, 这样看来XAML后面对于的CS文件可以被完全抛弃或不予理会了. 这样的XAML文件正是美工所需要的. 而这些对于Binding以及Command的定义描述以及其他相关信息的代码应该放在那里呢, 当然不是View, 更不是Model, 是“ViewModel“. ViewModel是为这个View所量身定制的, 它包含了Binding是所需的相关信息,比如Converter以及为View的Binding提供DataContext, 它包含了Command的定义以便View层可以直接使用, 另外,它还是一个变种的Controler, 它得负责业务流程的调度。于是, 便有了这副图, 然后, 正如“时势造英雄“所言, MVVM就诞生了.3、ViewModel 与单元测试如果你是一名正在使用MVVM模式打造软件的程序员, 那么我劝你尽快忘掉View. 你所面对的是这样一个模式“UnitTest-ViewModel-Model“(这并非一个模式, 仅仅是我为阐述观点而暂时如此表述的)。记得曾经有一个Model-View-AbstractView模式, 而MVVM中的VM实际也是一个AbstractView: the abstraction of view. 它是一个抽象的View, 具有一个View的灵魂,而不具备相应的可视化控件而已. 所以对于程序员而已, 打造这样一个抽象的VM就可以认为是完成View层的打造了.而当美工完成无数控件组成的实际的View后, 我们就可以用Binding和Command这样的黏合剂将这个抽象的View和实际的View黏合在一起了。那么在黏合之前, 我们怎么知道自己的VM是否正常工作呢? 单元测试!在说明对于ViewModel进行单元测试的重要性之前, 送给大家一句话: “View and Unit Test are just two different types of ViewModel consumers“ (Josh Smith). 如果我们将ViewModel看作生产者, 那么View和Unit Test都是具有同等地位的消费者而已. 并且UnitTest相比于View而言具备更大的消费能力. 或者你可以简单的认为View也仅仅是一种不太推荐的测试方式而已. 所以要实施好这个模式, 那么对ViewModel的单元测试就是必须的了,并且这个测试要不依赖于任何UI控件. (那么不是不对应ViewModel的开发是不是就应该通过测试来驱动了?TDD?
mvvm设计模式和mvc的区别以及优势
mvvm其实是mvc的变种而已。mvvm只是帮mvc中controller做瘦身，就是把一些逻辑代码和网络请求分离出去。网上有很多关于他们的讨论和文章，为了不让controller处理更多的东西，不让它变得臃肿，可以采用mvvm设计模式。如果界面交互比较频繁，我不太喜欢mvvm了，交互起来感觉不太方便，这只是个人感觉，也许是使用不太熟练吧！
mvvm框架是什么它和其他框架(jquery)的区别是什么哪些场景适合
MVVM 是 Model-View-ViewModel 的缩写。 Model 代表数据模型，也可以在 Model 中定义数据修改和操作的业务逻辑。View 代表 UI 组件，它负责将数据模型转化成 UI 展现出来。 ViewModel 监听模型数据的改变和控制视图行为、处理用户交互，简单理解就是一个同步 View 和 Model 的对象， 连接 Model 和 View。 在 MVVM 架构下，View 和 Model 之间并没有直接的联系，而是通过 ViewModel 进行交互，Model 和 ViewModel 之间的交互是双向的， 因此 View 数据的变化会同步到 Model 中，而 Model 数据的变化也会立即反应到 View 上。 区别：vue 数据驱动，通过数据来显示视图层而不是节点操作。 场景：数据操作比较多的场景，更加便捷
mvvm框架和mvc有什么不同
1.MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写。2.MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。3.MVVM模式和MVC模式一样，主要目的是分离视图（View）和模型（Model）4.最典型的MVC就是JSP + servlet + javabean的模式。也就是说，不管是MVC还是MVVM,都是为了使程序更加便利，用一个成语来说，叫做各司其职，每一层由每一层相应的工作，不会多做也不会少做，而MVVM也是与时俱进的产物，应对人们日益复杂的需求变化而产生的。