iOS组件化实践

    ReactiveCocoa只更新了一篇，剩下结合登录例子来实践MVVM暂时没有时间，这周精力都放在了公司项目的组件化上面，以后有时间会慢慢补上。感觉欠的历史债好多。
    对于大型项目来说，业务模块之间的耦合度非常大，很难维护。模块之间会互相调用。

传统模块

    为了解决这个问题，可以增加一个中间层。

增加中间层

    但是模块和中间层还是互相依赖，之前耦合的问题还是存在，要改进的地方是消除中间层对业务模块的依赖。

最终方案

模块的划分

    组件化是把每个模块作为一个组件，在主工程里面集成所有的组件。关于用CocoaPod集成私有库，在上篇文章CocoaPod创建私有库有详细的介绍。
    整个项目中模块的划分是分为基础模块、中间层和业务模块。

• 基础模块里面是和业务没有任何关联的模块，里面包括网络请求、图片加载、数据存储、页面布局还有公共的工具类等。
• 业务模块是按照功能来划分的。根据业务需要，来确定颗粒度的大小，比如登录注册模块、用户信息模块、购物车模块、详情模块、订单模块等。业务模块是要依赖基础模块的。
• 中间层不依赖业务模块，只负责调度业务模块。

---

模块之间的通讯

    消除中间层对业务的依赖，有三种方案。

• 蘑菇街 MGJRouter URL -> block
• 后来蘑菇街对这种方案提出改进protocol -> class
• casatwy大神的 基于CTMediator的Target -> Action

    下面重点介绍第三种方案。把所有组件的调用都通过category的方式暴露出来，调用方法

- (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params shouldCacheTarget:(BOOL)shouldCacheTarget;

    现在举个例子，首页要push登录页面。在中间层新建一个CTMediator的分类CTMediator+UMAction,暴露一个方法

- (UIViewController *)CTMediator_viewControllerForDetailWithValue:(NSString *)value;

    Target是UM,Action的对象是LoginViewController。然后再UM模块里面建立Target_UM文件，来处理LoginViewController的实例化。在首页调用

UIViewController * vc = [[CTMediator sharedInstance] CTMediator_viewControllerForDetailWithValue:@"我是标题"];
[self.navigationController presentViewController:vc animated:YES completion:nil];

    可以看到首页并没有引入LoginViewController的头文件。CTMediator 实际上是基于Runtime进行类名反射，将CTMediator+UMAction调用生成一个Target_UM。

NSString *targetClassString = [NSString stringWithFormat:@"Target_%@", targetName];
    NSString *actionString = [NSString stringWithFormat:@"Action_%@:", actionName];
    Class targetClass;
    
    NSObject *target = self.cachedTarget[targetClassString];
    if (target == nil) {
        targetClass = NSClassFromString(targetClassString);
        target = [[targetClass alloc] init];
    }
    
    SEL action = NSSelectorFromString(actionString);
return [self safePerformAction:action target:target params:params];

    所以每添加一个模块，都要在中间层声明一个分类来调用，同时也要在相应的模块内去实现这个Target。

---

关于组件化的思考

    实施组件化的大致的步骤，首先是把项目解耦拆分成一个个单独的组件，然后实现组件间的通讯。

• 组件化的好处
  简化了代码的整体结构，降低了维护成本，不同模块通过git管理，实现物理隔离，提高代码的稳定性，为模块的复用提供了基础，未来可以灵活的扩展业务。

• 组件化的缺点。
  学习成本高，对开发人员掌握各种工具要求比较高，入门比较困难，个人学习制作私有库，也是踩了好多坑。前期基业务没有实现，要提前考虑模块之间的解耦，过多的关注组件间的通讯，必然导致开发效率的下降。

    说一下项目，脱离实际项目谈架构都是扯淡。目前接手的项目是个电商类的项目，iOS 和安卓都还没有起步，web前端已经实现1.0版本，基本的电商的功能都实现了。iOS项目目前就两个人。项目想做成一个模板，然后给不同的客户提供可定制化的功能。项目管理人员想推行组件化，这周我在实践这一方案的可行性。
    并不是所有项目是适用于组件化。就对于现在的项目来说，只有两个开发人员。我来确定代码规范，不存在多人协同冲突的情况。产品虽然说后端接口和web前端都实现了，但是iOS和安卓项目都还没起步，实现最基础的业务，快速迭代上线更加重要，现有MVC或者MVVM就足够现实了。当实现了基础业务，需要更多对细节关注，才差不多要考虑组件化。
    组件化适合业务成熟且繁杂、开发人员多的大团队，对于我们两人且还没有开启项目的团队至少现在这个时间节点来说是不合适的。适合项目的架构就是好架构，组件化是好技术，但是在不合适的时候盲目追求组件化，是本末倒置的。

参考 :
在现有工程中实施基于CTMediator的组件化方案
iOS应用架构谈 组件化方案