MVC
MVC的优缺点
优点
MVC的低耦合性、高重用性、可维护性等优点显而易见，使得原本复杂的代码与界面的交互变得简单、清晰、明了，开发者可以把更多的精力放在前端界面的设计上，而不用绞尽脑汁去思考究竟应该如何使界面得到同步，这样减轻了设计压力，也从另一方面使用户得到更多更好的享受体验
缺点
1.愈发笨重的Controller
2.太过于轻量级的Model
3.较差的可测试性
- (MVC的另一个大问题是,它不鼓励开发人员编写单元测试。由于控制器混合了视图处理逻辑和业 务逻辑,分离这些成分的单元测试成了一个艰巨的任务。大多数人选择忽略这个任务,那就是不做 任何测试。
上文提到了控制器可以管理视图的层次结构;控制器有一个“view”属性,并且可以通过IBOutlet访 问视图的任何子视图。当有很多outlet时这样做不易于扩展,在某种意义上,最好不要使用子视图 控制器(child view controller)来帮助管理子视图。
在这里有多个模糊的标准,似乎没有人能完全达成一致。貌似无论如何,view和对应的controller 都紧紧的耦合在一起,总之,还是会把它们当成一个组件来对待。Apple提供的这个组件一度以来 在某种程度误导了大多初学者,初学者将所有的视图全部拖到xib中,连接大量的IBoutLet输出口属 性,都是一些列问题。
)
4.遗失的网络逻辑
- (苹果使用的MVC的定义是这么说的:所有的对象都可以被归类为一个Model,一个view,或是一个 控制器。就这些。那么把网络代码放哪里?和一个API通信的代码应该放在哪儿? 你可能试着把它放在Model对象里,但是也会很棘手,因为网络调用应该使用异步,这样如果一个网 络请求比持有它的Model生命周期更长,事情将变的复杂。显然也不应该把网络代码放在view里, 因此只剩下控制器了。这同样是个坏主意,因为这加剧了厚重控制器的问题。)
5.定义模糊的“Manage”
______之前我提到了view controller可以管理试图的层次结构；view controller有一个“view”属性，并且可以通过IBOutlet访问视图的任何子视图。当有很多outlet时这样做不易于扩展，在某种意义上，最好不要使用子视图控制器（child view controller）来帮助管理子视图（subview）。要点在哪？验证用户输入的业务逻辑应归入controller还是model呢？在这里有多个模糊的标准，似乎没有人能完全达成一致。貌似无论如何，view和对应的controller都紧紧的耦合在一起，总之，还是会把它们当成一个组件来对待。
MVVM
在经历了一大堆吐槽之后,诞生了MVVM(一个高大尚牛逼哄哄的名词,从此又多了一种人,你懂MVVM ？如果你的回答是否,瞬间被鄙视一把)。
Model-View-ViewModel
-
1.在MVVM里，view和view controller正式联系在一起，我们把它们视为一个组件。视图view仍然不能直接引用模型model，当然controller也不能。相反，他们引用视图模型view model。
-
2.view model是一个放置用户输入验证逻辑，视图显示逻辑，发起网络请求和其他各种各样的代码的极好的地方。有一件事情不应归入view model，那就是任何视图本身的引用。view model的概念同时适用于于iOS和OS X。（换句话说，不要在view model中使用 #import UIKit.h）
优点
- 1.由于展示逻辑（presentation logic）放在了view model中，视图控制器本身就会不再臃肿。当你开始使用MVVM的最好方式是，可以先将一小部分逻辑放入视图模型，然后当你逐渐习惯于使用这个范式的时候再迁移更多的逻辑到视图模型中。
- 2.使用MVVM的iOS app是高度可测试的；因为view model包含了所有的展示逻辑并且不会引用view，所以它可以通过编程方式充分测试
- 3.使用MVVM会轻微的增加代码量，但总体上减少了代码的复杂性。这是一个划算的交易。
为什么要mvp
- MVC、MVVM,真实的业务场景中,如果场景的逻辑异常复杂,在反复的迭代中仍会出现 各式各样的问题。真对MVVM我个人理解主要是将原来Controller中处理数据逻辑的代码统一归 到一个新的class(viewModel)中去,更甚之网络请求等工作全部从Controller移到viewModel。 刚一开始总觉的怪怪的。
- MVVM层将对应的 一部分逻辑处理移植到了ViewModel中,这并没有从根本上解决问题,无非是将代码做了一份对应 的copy转移,并没有从根本上达到逻辑分层的概念。相反MVP模 式恰好解决了这一难题,MVP模式衍生于传统service架构,针对不同的业务场景图供对应的匹配的 抽象service服务,客户端拿到网络数据后未达到指定的目的,为满足相同抽象逻辑的业务场景,在客户端网络层与Model层之间加一协议层,Model层实现整个 协议层,之后在基于MVC的结构下将一概相同层次的,业务场景绘制解释到对应的View上。
MVP
传统web架构
(DTO是一个普通的Java类，它封装了要传送的批量的数据。当客户端需要读取服务器端的数 据的时候，服务器端将数据封装在DTO中，这样客户端就可以在一个网络调用中获得它需要的所有数据。)
现有模式:
mvp模式
- M : 逻辑Model层
- V : 视图层
- P : protocol协议层
- Model层类似于MVVM的ViewModel,主要负责存储抽象逻辑数据,另外Model层主还有部分工作 实现对应的协议层协议,提供协议对应的各种属性以及服务。Model经过协议层抽象约束,最后 Model被抽象成具有统一抽象逻辑的业务场景,最终Model层在讲数据交付整个MVC结构绘制展 示的时间,我们可以按照同一套抽象的逻辑标准去执行。