iOS开发中的MVVM架构理解与实践
概述
MVVM作为一种流行的软件架构模式，旨在解决开发过程中Controller过于庞大且难以维护的问题。在MVVM中，数据加工的任务从Controller中被出来，而由ViewModel负责。Controller则专注于数据调配，而ViewModel则通过通知机制让View响应其改变。下面将详细介绍我对MVVM的一些理解与实际应用。
关于MVVM的误解与理解
许多资料在阐述MVVM时容易给人造成一种错觉，即MVVM不需要Controller。实际上，MVVM是一定需要Controller的参与的。虽然MVVM在一定程度上弱化了Controller的存在感，为其减负瘦身，但并不代表MVVM中不需要Controller。严格来说，MVVM其实是MVC的一种变体，其中C（Controller）的作用是将V（View）和VM（ViewModel）进行绑定。在逻辑上，Controller知道应当展示哪个View，也应知道应当使用哪个ViewModel，然而View和ViewModel之间是相互独立的，所以Controller就负责控制他们的绑定关系。说使用MVVM之后就不需要Controller是不准确的。
MVVM架构详解
在实际应用中，我们将页面进行拆分，首先是控制器（Controller），然后是视图（View）。为了管理View的常规事件和View的生命周期，我们引入了ViewManger。而关于业务逻辑和网络请求的部分则存放在ViewModel中。这种设计的目的是保持View和Model的高度纯洁，提高可扩展性和复用度。
以一个简单的页面为例，界面上有MyBtn按钮和MyView复杂子视图等。首先我们需要建立ViewModel，让它能够生产数据并提供给Controller；然后建立ViewManger来管理MyView；Model模型数据也是必不可少的。
在日常开发中，ViewModel是为了拆分Controller业务逻辑而存在的，因此ViewModel需要提供公共的服务接口，以便为Controller提供数据。ViewManger的作用相当于一个小管家，帮助Controller来分别管理每个subView。Controller则是最后的大家长，负责将ViewModel和ViewManger进行绑定，进行数据转发工作。
在代码实现上，MyViewModel主要负责数据的加载和处理，MyViewManger则负责接收处理来自所管理View的一些事件、布局当前View等。而MyView主要负责管理自身的内部控件视图，并根据业务逻辑需要定义一些基本事件，通过交给ViewManger来实现。
关于是否采用更轻量级的ViewController做法，即将各个protocol的实现挪到ViewController之外来为ViewController瘦身，众说纷纭。在实际开发中，如果页面逻辑较为简单，可以将部分逻辑抽离到单独的Handler中管理；但如果页面逻辑复杂，可能需要将protocol重新请回Controller中，因为View层与ViewController层本身是持有与被持有的依赖关系。
MVVM架构的核心思想是将业务逻辑与界面展示分离，通过ViewModel作为中间层进行数据的加工与传递。在实际应用中，我们应根据项目的具体情况进行分析，采用最合适的方式来处理应对不同的问题。本文的相关Demo可以在github上找到（/lovemo/MVVMFramework），仅供参考，欢迎补充。如果想学习更多关于MVVM的文章，可以查阅推荐文章。
