移动客户端业务层组件化（2）- 不重复造轮子

我们要坚信绝大部分问题，其他人早就遇到过，并且很可能有绝佳的解决方案，即使没有，至少别人踩过的坑，我们不必再踩一次。所以对于组件化，也是一样，我们要避免重复造轮子。于是，第一件事我们要做的就是找这个轮子。

iOS的两个轮子：

（1）Limboy（蘑菇街）的组件化方案：
http://limboy.me/ios/2016/03/10/mgj-components.html
http://limboy.me/ios/2016/03/14/mgj-components-continued.html
（2）Casa（天猫）的组件化方案：
http://casatwy.com/iOS-Modulization.html

这两组文章可以结合着看，非常有意思，另外底下评论的内容更精彩，有点像两个高手在擂台上切磋，底下有一堆围观助威点赞的。
文章自己看就好，很长，内容很丰富，甚至Casa还写了一个Demo来论证自己的观点，我们去粗取精，深入分析一下：

英雄所见略同：

我们先看看两个同学意见相同的地方：

1. 组件间的通讯涉及到传参问题，那么这个参数首先需要去Model化，否则调用者和被调用者都需要持有Model的引用，达不到解耦的目的。
   (去Model化会带来一个问题，就是参数需要以NSDcitionary的方式传递，势必会影响开发效率，因为调用双方需要约定好各种Key，以及Key有问题时能够准确抛出相关的异常)
2. 组件间通讯的参数需要分为常规（能够使用JSON进行序列化的对象）和非常规。
3. 对于远程APP调用，都使用openUrl的方式（这个算是废话，苹果只支持这个），并且过程基本一致：openUrl-> parse-> target-action

求同存异

再看看两个同学意见相左的地方：

1. 发现服务：
   Limboy采用应用初始化，各个组件向ModuleManager注册的方式。
   Casa采用iOS runtime机制，使用Mediator+target-action方式自动发现服务，免注册化。
2. 组件间通讯问题：
   Limbo的方案，对于常规参数，使用openUrl方式，非常规参数使用注册protocol的方式，通过publicProtocol暴露出需的类和方法，所有组件持有这个publicProtocol。
   Casa的方案，分为远程调用和本地调用，远程调用的方式是openUrl方式，本地调用采用target-action方式，通过category将方法暴露出去，省去了注册的这一步。
3. 调用组件页面的细节：
   Limbo的方案是：调用者传入相关参数发起调用 -> 响应方收到调用 -> 响应方创建页面实例并pushViewController。

[MGJRouter registerURLPattern:@"mgj://detail?id=:id" toHandler:^(NSDictionary *routerParameters) {
    NSNumber *id = routerParameters[@"id"];
    // create view controller with id
    // push view controller
}];

Casa的方案是：调用者传入相关参数发起调用 -> 响应方收到调用 -> 响应方创建页面实例并返回 -> 调用方拿到实例后进行处理。

我们可以看到Limboy方案的好处是：调用方不需要关心响应方的逻辑，只需要正确调用方法和传递参数即可，缺点是不够灵活，如果调用方想Present而不是Push呢？而Casa的方案正好相反。
我个人更倾向Casa的方案，虽然代码会长一些，但是清晰，对于这种跨组件的调用，清晰是第一位的，否则业务工程师很容易懵逼。

推荐另外一个同学bang（JSPatch的作者）的分析：http://blog.cnbang.net/tech/3080/