中小型App的架构

引言

我的对于架构比较感兴趣，平时有事没事的都会逛逛博客，看看书。而后组长要我分享下关于架构的知识。先来写一份博客捋捋思绪吧。 MVC模式，我的以为是架构模式里最强大的模式！能给予不少的架构启发（包括后面出现的MVP,MVVM）。对于中小型App，简单的MVC或者MVPC模式会更合适点。本文是基于MVC的思想去写的。

Model还有胖瘦？

早在几年前吧，国外对于胖瘦model这个概念，争执了好久，最后的结果仍是不了了之。。。由于不管是胖model仍是瘦model，都各自具备各自的优缺点。那么什么是胖瘦model呢？ 所谓的胖model就是说，你的Model层上包含了部分弱业务，瘦Model就是单纯的Model，只有属性的映射。 举个🌰： 好比说你的UserModel里有性别这个熟悉，可是后台返回或者数据库存储的字段是0和1，你须要根据这个字段去判断男和女。若是是胖Model选手呢，很简单啊，我在个人Model层里就作好这些简单业务的判断，到时候ViewController须要用到的时候直接用就行了。可是胖Model比较难移植，并且修改或许会形成某些没必要要的麻烦。而瘦model选手就不一样，个人Model能够很是方便的直接ORM映射，我在个人ViewController里须要用的时候去判断下。不过这样的结果就是违法了DRY原则(don't repeat yourself)。由于不少冗余的代码没有抽象出来，这样的VC层看起来很臃肿。

至于个人态度，我更倾向于胖Model。传统的MVC模式，会让VC层很是的臃肿，早以前就不少人提出要给VC层瘦身。因而乎就把部分弱业务写在model里了，胖Model所以诞生了。至于后来的MVP，MVVM什么的就更加抽象了。

什么是架构

什么是架构，可能不少人上来就是MVVM，MVC，而后罗列出一系列的优缺点巴拉巴拉。。。我我的以为架构就是架构师根据当前业务复杂度和业务工程师去设计框架，目的就是让业务工程师在写业务的时候统一，方便，明白。并且能够比较简单的上手，迁移，包括以后的演化也须要考虑到。 对于中小型的App来讲，业务工程师不会不少，业务也不会很复杂。因此能够基于MVC作一些简单的拆分（抽象）。

总体架构

整体是基于MVC，多加了一层Reformer。做用是将胖Model中的若业务部分抽出来，ViewController中的部分业务抽出来，放在Reformer中。因此咱们的网络层的接口能够这样设计

+ (void)requestBubleList:(BaseReFormer *)reformer
                     xxx:(NSString *)xxx
                callBack:(void (^)(int code))callback;
复制代码

业务程序猿只须要关注本身须要作什么数据处理，业务逻辑，在Reformer中写好。而后传入这个Reformer和请求须要的参数就能够了，至于网络层作了什么，其实并不须要了解。 Reformer用于处理业务和数据，Model用于数据管理，View用于数据展现，ViewController用于协调Model和View，而且响应交互（可能会涉及到部分业务）。

整体来讲，弱化了原先在MVC中C层的做用，而且在设计过程当中，少用继承，多用组合，将可以复用的代码用管理类管理起来。我把这个叫作MRVC框架（O(∩_∩)O哈哈~）

总体代码框架

框架又基于业务去设计和区分，为了能够更好的分工合做，更好的迁移代码。 第一个Util里放公共的代码，和业务无关的工具类。好比说各类第三方的封装，分类。 第二个'Dao'里放的是和总体业务相关的工具类，好比说公共数据库，公共网络接口API。 第三个就是App涉及到的业务。 Lib是没有pod库导入的第三方库。 Res就是资源库，放图片，Assets。 外面就是Base类，Base类里不要放业务相关的代码，就放基础配置和基本API。

业务代码层框架

当具体到某个业务里的框架设计呢，咱们会将网络层也作业务区分，而且散落到各个业务模块中。能够看到最上面是数据来源（不管后台返回仍是数据库都是数据的来源）。中间的Mediator层是用于业务跳转的，咱们大部分时候写页面跳转都是这样写的：

XXXViewController *controller = [XXXViewController new];
[self.navigationController pushViewController:controller animated:YES];
复制代码

这样的坏处是A程序猿须要跳转到B程序猿负责的已经完成的某一个业务页面，可是A不熟悉B的代码，就要去问B，若是B不在的话，就要找，可能会好久，若是须要带参数就更加尴尬了。因此咱们能够添加个B业务的Mediator层的，用于跳转。跳转的接口都设计好，举个🌰：

UserMediator.h

/**
 跳转到我的详情页面

 @param from 跳转的页面
 @param user_id 用户ID
 @param nickName 用户昵称
 */
+ (void)pushUserInfoContoller:(UIViewController *)from
                       userID:(long)user_id
                     nickName:(NSString *)nickName;
复制代码

当咱们须要用到的时候，就调用[UserMediator pushUserInfoContoller:self userID:10086 nickName:@"中国移动"]。对于A来讲去看看Mediator层的文档就可使用了。

因此说业务层的框架设计能够以下图所示：

总结

这个架构的好处 1.总体是分业务模块设计的，业务与业务之间没有直接的耦合，由于中间多了层Mediator层。因此说业务的复用和迁移相对来讲比较简单，对于从此若是想要模块化也能够进一步迭代。若是还须要解耦合，就用runtime和dictionary传参的方式，可是这样的成本相对较高，对于API直观程度不够。 2.总体是MRVC设计，因此是轻量级的V层和映射级的Model层，中间业务都基本处于Reformer层。若是须要响应式编程的话，能够在Reformer层进行设计修改。 3.少用继承，多用组合。对于代码迁移有很大的方便性，拔出萝卜带出泥的这种现象会不多。 4.网络层接口的分模块能够和后台架构保持一致，对于总体架构都比较好。