MVVM(微软的WPF基础)-MVC(经常使用模型/设计)-WPF(微软.NETFramework3.0

最近看 好多人说IOS MVC 过期了 要用MVVM 什么什么的，感受 很新奇，就去搜了一下，发现原来所谓的MVVM就是 以前微软在10年左右就推出的WPF ，鄙人不才，搞过两年多的C#开发，所以 作了下比较：

首先来看一下 WPF

WPF（Windows Presentation Foundation）是微软推出的基于Windows Vista的用户界面框架，属于.NET Framework 3.0的一部分。它提供了统一的编程模型、语言和框架，真正作到了分离界面设计人员与开发人员的工做；同时它提供了全新的多媒体交互用户图形界面。

那么 模式MVVM就是：

再来看下经典的MVC：

其实这就是 把VIEW层 再次分一下 分红view和view controller层 这让我想起了 以前的三层架构和MVC

三层架构是最基本的项目分层结果，而MVC则是三层架构的一个变体，MVC是一种好的开发模式。首先你要明白MVC分别表明的是什么意思.
M 即Model(模型层)，主要负责出来业务逻辑以及数据库的交互
V 即View(视图层)，主要用于显示数据和提交数据
C 即Controller(控制器)，主要是用做捕获请求并控制请求转发

三层:UI 界面层 BLL 业务逻辑层，DAL数据访问层，Model 实体层
MVC中的的M 不是三层中的Model(实体层)，他其实包括三层中的 BLL，DAL,Model,这是很是要注意的，这也是他们之间的区别的关键所在

其有点有以下：
低耦合性
高重用性和可适用性
较低的生命周期成本
快速的部署
可维护性
有利于软件工程化管理

固然优势也有缺点，那就是内部结构复杂，不容易理解，文件数量大，管理难度天然也就大

其实 原本是没有区别的 或者说 是相互关联的 具体就是

能够看出，三层架构就是把不一样的层次打乱 而后拆分出新的层次，这就是区别，额，感受 如今的模式都是这样 ，可能对易老程序员来讲，原来的用的顺手了，可是 对于初学者，这些感念简直就是噩梦，MVC是一种万金油同样的存在，你说他是设计模式也好，框架也好，总之我认为 好用就行，全部的这些拆分或者从新组装都是为了更好地分离视图和逻辑代码以及数据库交互，只要你的逻辑清晰，分清楚之间的关系，我以为很容易理解，固然这也有牵扯到内聚耦合什么的，但这不是咱们讨论的重点。

关于三层架构有一个很经典的例子用于区分各个层次之间的关系，很好理解，和诸位分享一下：

一个客户 也就是用户  走进了一家餐馆 点餐  叫服务员点菜 而后服务员去把单子给厨师  炒完菜 服务员将菜端给你 这儿过程当中产生数据  也就是制造菜的是厨师  相似于数据层 他只负责炒菜  他不知道客户是谁  只经过服务员 来告诉他
服务员沟通客户和厨师 业务逻辑层  客户可能有多个需求  厨师也可能同时炒多个菜  由业务逻辑层也就是服务员负责调度 安排   装菜的盘子  也就是 显示层  他决定了 如何呈现菜  是大盘 仍是小盘 不一样样式 服务员点菜的单子  使咱们所说的实体层  它相似于一个模子 一个传输数据 需求 的模板

MVC缺点有哪些呢？咱们来看看那些大神的吐槽的MVC四大“缺点”：

一、厚重的View Controller

因为大量的代码被放进view controller，致使他们变的至关臃肿。在iOS中有的view controller里绵延成千上万行代码的事并非前所未见的。这些超重app的突出状况包括：厚重的View Controller很难维护（因为其庞大的规模）；包含几十个属性，使他们的状态难以管理；遵循许多协议（protocol），致使协议的响应代码和 controller的逻辑代码混淆在一块儿。厚重的view controller很难测试，不论是手动测试或是使用单元测试，由于有太多可能的状态。将代码分解成更小的多个模块一般是件好事。

二、遗失的网络逻辑

苹果使用的MVC的定义是这么说的：全部的对象均可以被归类为一个model，一个view，或是一个controller。就这些。那么把网络代码放哪里？和一个API通讯的代码应该放在哪儿？

你可能试着把它放在model对象里，可是也会很棘手，由于网络调用应该使用异步，这样若是一个网络请求比持有它的model生命周期更长，事情将 变的复杂。显然也不该该把网络代码放在view里，所以只剩下controller了。这一样是个坏主意，由于这加重了厚重View Controller的问题。那么应该放在那里呢？显然MVC的3大组件根本没有适合放这些代码的地方。

三、较差的可测试性

MVC的另外一个大问题是,它不鼓励开发人员编写单元测试。因为view controller混合了视图处理逻辑和业务逻辑，分离这些成分的单元测试成了一个艰巨的任务。大多数人选择忽略这个任务，那就是不作任何测试。

四、定义模糊的“Manage”

以前我提到了view controller能够管理试图的层次结构；view controller有一个“view”属性，而且能够经过IBOutlet访问视图的任何子视图。当有不少outlet时这样作不易于扩展，在某种意义 上，最好不要使用子视图控制器（child view controller）来帮助管理子视图（subview）。

要点在哪？验证用户输入的业务逻辑应纳入controller仍是model呢？

在这里有多个模糊的标准，彷佛没有人能彻底达成一致。貌似不管如何，view和对应的controller都牢牢的耦合在一块儿，总之，仍是会把它们当成一个组件来对待。

总结一下MVVM：

在MVVM里，view和view controller正式联系在一块儿，咱们把它们视为一个组件。视图view仍然不能直接引用模型model，固然controller也不能。相反，他们引用视图模型view model。

view model是一个放置用户输入验证逻辑，视图显示逻辑，发起网络请求和其余各类各样的代码的极好的地方。有一件事情不该纳入view model，那就是任何视图自己的引用。view model的概念同时适用于于iOS和OS X。（换句话说，不要在view model中使用 #import UIKit.h）

因为展现逻辑（presentation logic）放在了view model中（好比model的值映射到一个格式化的字符串），视图控制器自己就会再也不臃肿。当你开始使用MVVM的最好方式是，能够先将一小部分逻辑放 入视图模型，而后当你逐渐习惯于使用这个范式的时候再迁移更多的逻辑到视图模型中。

使用MVVM的iOS app是高度可测试的；由于view model包含了全部的展现逻辑而且不会引用view，因此它能够经过编程方式充分测试。虽然有众多的hack技术参与到测试Core Data模型，但使用MVVM写的app能够进行充分的单元测试。

以个人经验，使用MVVM会轻微的增长代码量，但整体上减小了代码的复杂性。这是一个划算的交易。

再看一下MVVM那张图：

回过头再来看MVVM的图示，你会注意到我使用了模糊的动词“notify”和“update”，而没有详细说明该怎么作。你可使用KVO，就像MVC那样，但这很快就会变得难以管理。事实上，使用ReactiveCocoa会是更好的方式来组织各个部分。

用如今流行的那个词说就是 用人话讲MVVM就是：

Model层是少不了的了，咱们得有东西充当DTO(数据传输对象)，固然，用字典也是能够的，编程么，要灵活一些。Model层是比较薄的一层，若是学过Java的小伙伴的话，对JavaBean（陌生的自觉参考上边的图片）应该不陌生吧。

ViewModel层，就是View和Model层的粘合剂，他是一个放置用户输入验证逻辑，视图显示逻辑，发起网络请求和其余各类各样的代码的极好的地方。说白了，就是把原来ViewController层的业务逻辑和页面逻辑等剥离出来放到ViewModel层。

View层，就是ViewController层，他的任务就是从ViewModel层获取数据，而后显示。

最后

放几张 我从网上找的别人设计的MVVM的 框架 目前我也正在研究 具体是MVC好仍是MVVM好 仁者见仁智者见智，，，