APP架子迁移指南（一）

搭架子是脑垂体在放烟花

俗话说吃多少饭，走多少路，上学的时候捧着《设计模式》就想睡觉，现在轮子看得多了，自然有心领神会之感。搭架子就像谈哲学，如高山流水，遇弯则急、遇潭则深。我印象最深的是一次酒过三巡，一位德高望重的前辈讲释迦牟尼的故事：有人问释迦牟尼”恒河的沙砾有多少？“，释迦牟尼答：“恒河的沙砾比银河的星星还要多。”对科普过的我们这一比喻看似普通寻常，但是在那时候对宇宙根本没有多少认识的年代，能做出这样的判断，是需要怎样的大智慧才能办到？

搭架子就是一个思考恒河沙砾数量的过程，不应被DAL、MVC、MVP、MVVM、DDD、充血、贫血这些术语固化，这些是规范、是交流语言（DDD里面还专门讨论了这个事），目的是为了让你或者团队的其他人能够看懂你在干什么（如PHP中的PSR-X规范一样），只是告诉你“数沙砾的步骤”；选择用哪个规范来完成，才是思考恒河沙砾数量的过程（比如你直接复制一个MVP的项目模板作为架子蓝本，为什么要复制一个蓝本直接用，因为你心里有数这样做最快、最省事，这就是一个思考过程）。

再举个例子，剑法巅峰讲究“合一”境界，人剑合一、见招拆招、凌波微步，忘记所有剑谱和步数，心指剑到，唯我不破。搭架子，是“人剑合一”的过程，你可能会画草图、会写需求文档，但都是在心中刻画整个轮廓；写代码，是在重演剑谱，因为剑谱你已经摆了几百盘，你知道listview需要adapter、tableview需要算高度；用轮子，是在见招拆招，你可以用Glide或者SDWebImage、或者干脆直接用AFNetworking自带的图片扩展。

架子迁移，是从无序的代码结构中进行提炼和总结，以MVP、MVVM等思路对代码进行重构。搭一个架子根本不是性能，而是为了体现更好的代码规范和功能扩展（白话就是什么代码写到哪个文本文件里面，如Presenter里面放交互代码）。

讨论之前先明确几个思路

DDD里面特别提到过一个观点我非常赞同--UBIQUITOUS LANGUAGE(通用语言)，就是首先要理清楚我们到底是在讨论什么，这样才不会误会，思想才能连贯。比如我说“苍老师”，你我都知道我们在谈什么；但我要是说“陆家嘴”，你以为我是在说那个视频，我其实是在说一个地名。这里套用这一概念，先说说我搭架子的几个思路。

1.不要用力过度。一个几千万把块钱的项目，就别思考用DDD（DDD是我见过最高深晦涩的架子思路）把业务拆分成领域然后还要设计接口和工厂了。一个基础架子的代码量都比你实际功能写的代码量多。

2.不要被MVP、MVVM唬到了。举个例子，之前你可能会用一个BaseXXX把社交分享、界面初始化的代码写在里面，XXX继承该类，然后就只需要把某个按钮的逻辑写出来，这样一个文件里面的代码行数就降下来了，读起来就清爽了。MVP、MVVM干的就是这种事，如出一辙，只是更规范而已。

3.设计模式不是架子。同样是开发思路，但设计模式是针对某一逻辑功能的实现策略。比如社交分享，你可以用工厂模式实现QQ、微信、微博（都有个成功、失败的状态，只是发送的数据不一样），代码写在哪个文件里面，放在哪个包里，就是架子考虑的事。

4. 现在火的不行的RxXXXXXX不是架子，是轮子（更直白的说是技术网红找优越感的罩杯，MVVM也是，这些在.NET3.5时代就玩腻的东西，拿来还当宝了:P）。响应式编程值得学习，但没有达到完全取代Handler的高度。

现在的架子哪里不好了

APP到底要不要用一种模式来搭架子，是一个需要权衡的想法。APP说白了和Winform一样就是个展示层（Presentation），做过Winform的都知道，一个DAL三层模式就足以胜任大部分工具软件的需要了。所以没有必要把APP开发想象的那么高深莫测，就是一个网络访问-》数据读取-》数据显示的过程，用包或者Xcode里面的group区分业务模块，就是一种简单并且特别实用的架子。

初期架构

上图就是一个典型ios架子，通用工具类没画出来，但应该可以理解（比如时间处理）。一个模块为一个Group（如首页），首页模块的代码按MVC分离，所有功能逻辑全部放在Controller中，有不妥么？没有任何不妥，功能一个不落可以实现，但.M文件就显得太臃肿了。

分离网络通信

上图做了简单的剥离，把网络通信模块从Controller中取出来，放在Manager中。Controller的.M文件是不是就感觉干净多了？其实还可以继续剥离，把TableViewCell的数据绑定放到Model中去，把数据库缓存等写到一个叫Task的文件中去。从我读过的不下10个开源项目看来，到这一步，就是现在最常见的架子结构了，代码复杂程度可以接受、架子伸缩自如，其他模块只是复制加粘贴的问题了。

对Android来讲，架子可以说一模一样，只是多了一个adapter，Controller变成了Activity或者Fragment。从功能实现上讲，有问题吗？也没有任何问题。那么为什么要考虑用MVVM或者MVP模式呢？如果你有强迫症，喜欢把MM豆根据颜色归类；或者随着功能的增加或参与人员的增加，你会慢慢觉得Contoller中写的代码开始乱套找不到你想要的东西，直觉会告诉你，是时候需要一套基于单一原则的架子来重构项目了。

架子就像写八股文

在前文讨论了UBIQUITOUS LANGUAGE(通用语言)这一概念，常见关键字如Manager、Domain、Service、Biz、Helper，其实文件里面写的代码干的都是一码事，但都是不同架子模型中的术语（如Domain是DDD中的术语）。如果是个团队，即使见多识广，也不推荐混淆使用术语，这样容易造成困惑，有些事情还是较真一点比较好。另外，各种架子需要基础代码或文件来搭建，比如MVP模式中有一个XXXContract文件，定义行为接口。这些代码会增加工作量，但却值得老老实实的创建，因为这些架子基础代码可以更好的执行逻辑隔离和单一原则行为，让代码更好理解。

所以搭架子就像写八股文，就像写论文一样，不是搞艺术创作，你不是诗人。规范的目的就是为了层次清晰，当你习惯架子规范后，你在看到文件名的时候就心中有数，应该如何继续如何继续开发了。

接下来的文章

我在看架子的时候一直对“业务逻辑和功能逻辑要分离”等等很晦涩的话感到困惑，接下来的文章我都希望能通过实例代码让你搞明白这些究竟是在讲些什么东西。全文以我开源的社交APP“独白故事”及多个github开源项目为代码蓝本进行解释，总结一下自己对架子的理解，顺便也把独白故事更新一下：）