type
status
date
slug
summary
tags
category
icon
password
项目 demo 地址：
MVC：
MVVM：
优点：
MVC：
1、苹果推荐
2、简单易用，所有开发者几乎都可以直接上手
3、可扩展性强，逻辑复杂时也可以在 MVC 架构上一定不可以加一个 ViewModel
MVVM：
1、View 可以独立于 Model 的变化和修改
2、一个 ViewModel 可以复用（比如我们可以把选择图片的逻辑封装在一个 ViewModel 中，我们只需要最终得到图片）
缺点：
MVC：
臃肿的 C 层代码
MVVM：
过于简单的项目不适用，大型项目视图状态较多时构建和维护成本过高
这里推荐一片参考文章
根据文章思路，可拆分 Controller 和 View 视图
文章给了我很大启示，并且简洁明了，但是有一些不成熟的想法：
1、在项目中期接手项目，项目中已经有了 Controller 的基类时，无法对基类进行更改
2、在项目中期接手项目，项目中已经有了 Controller 的基类时，如拆分 Controller 和 View 的基类继承与原有基类，造成继承过多。第三层的继承是滥用的开始
3、父类和子类是一种高耦合，牵一发而动全身，违反了面向对象思想
我的思路：
1、面向切面，hook 所有自定义 Controller 的 loadView 方法
2、独立出协议，在协议类中为所有需要绑定的 Controller 绑定 View
使用时（协议实现）：
我们只需要为每一个控制器手动遵守 MVCProtocol 协议，并在协议中设置好需要绑定的 View 即可
具体实现：
在控制器中就可以直接调用到 container 属性去进行配置 view 以及模型了
该项目的缺点：
1、如果 AController 遵守了 MVCProcotol，BController 继承 AController 就无法更改为 BView，只能继续使用 AView，也不建议继承这么用，组合复用模式嘛
2、考虑到直接交换 UIViewController 的 loadView 方法过于极端，项目中应尽可能避免或者尽可能少的交换方法，该项目没有对整个 UIViewController 的 loadView 方法进行替换。项目自动提取了所有遵守 MVCProcotol 协议的类，只对遵守 MVCProcotol 协议的类进行了替换。
3、因为第二个缺点，我们交换了所有遵守 MVCProcotol 协议的类，但是在 Appdelegate 的 didFinishLaunchingWithOptions 方法中交换过多的方法会导致启动变慢（积少成多嘛），所以提供了 launch 方法，在 launch 方法中只填入首页要加载的控制器就好，如果全部写入会导致启动速度变慢！！如
总结：
没有人强制使用了 MVC 就不可以使用 ViewModel，在合适的时候依然可以添加 ViewModel类，比如我们可以把选择图片的逻辑封装在一个 ViewModel 中，我们只需要最终得到图片
没有哪个架构模式完美匹配所有项目，开发者要根据需求去匹配架构模式
- 作者:NotionNext
- 链接:https://tangly1024.com/article/iOS%20%E6%9E%B6%E6%9E%84%20MVC%20%E4%B8%AD%20Controller%20%E5%92%8C%20View%20%E9%9D%A2%E5%90%91%E5%88%87%E9%9D%A2%E6%8B%86%E5%88%86
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章