前言###
闲来无事就看看代码，重新设计项目的架构，发现猿题库的架构设计和我之前项目的架构差不多，只有一点点的变化（从dataSource变成dataController）,今天就略微整理一下思路，以便大家参考。
作者声明：每个架构都是各有优缺点，没有最好，只有不断完善适合自己项目业务场景的架构才是好架构。
简单比较###
1、MVC是我们最常用的，Model-View-Controller，最经典的关系图如下：
MVC经典关系图.png
优点：简单、成熟、容易操作
缺点：越来越难适应项目的开发需求，容易引出愈发笨重的 Controller
2、MVVM是MVC的升级版，Model-View-ViewModel，主要是把网络请求和一些数据加工的方法放到ViewModel中来处理，现在主要的应用形式有两种
A、ViewModel放在Controller与Model之间，分摊Controller的业务逻辑、网络请求、数据加工等逻辑
MVVM模式一的用法.png
B、ViewModel放在Controller与View之间，用作视图数据的包装、加工
MVVM模式二的用法.png
优点：解决了MVC中胖Controller的问题；
缺点：ViewModel 依然承载的大量的逻辑，包括业务逻辑，界面逻辑，网络数据处理，也有可能造成ViewModel臃肿
MVVM可以这样玩###
以上要解决问题的本质问题是分担控制器的责任，所以我们可以把一些逻辑细化、分层处理，结合MVC+MVVM的优点并把一部分逻辑增加到另一绑定的控制器中，就可以解决问题。如图解说：
MVVM+DataController.png
这里使用的DataViewController是与ViewController一一对应的关系
ViewController 可以向 DataController 请求获取或是操作数据，也可以将一些事件传递给 DataController，这些事件可以是 UI 事件触发的。DataController 在收到这些请求后，再向 Model 层获取或是更新数据，最后再将得到的数据加工成 ViewController 最终需要的数据返回。这样数据的获取、修改、加工都放在 Data Controller 中处理，控制器的业务逻辑更加清楚。
优点：层次清晰，逻辑结构明确、耦合性低，解决了某个层臃肿的现状；
缺点：代码调试比较不方面，交互太多时，信息传递会产生过多的胶水代码。
结论###
每个项目的架构和业务场景有很大的关系，打造最适合自己项目的架构才是明智之举。
最后赠言###
如果觉得文章对您有帮助，不要忘记star哦!😝，star 是对程序猿最大的鼓励！
网友评论