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四大“缺点”：

1、厚重的View Controller

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

2、遗失的网络逻辑

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

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

3、较差的可测试性

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

4、定义模糊的“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好 仁者见仁智者见智，，，