APP架子迁移指南（一）

搭架子是脑垂体在放烟花

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

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

再举个例子，剑法巅峰讲究“合一”境界，人剑合1、见招拆招、凌波微步，忘记全部剑谱和步数，心指剑到，惟我不破。搭架子，是“人剑合一”的过程，你可能会画草图、会写需求文档，但都是在心中刻画整个轮廓；写代码，是在重演剑谱，由于剑谱你已经摆了几百盘，你知道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开源项目为代码蓝本进行解释，总结一下本身对架子的理解，顺便也把独白故事更新一下：）