BeeHive组件化

理解关于Beehive的设计思想

Beehive的使用, 可以分3个核心的内容
1.Service 服务
2.Module 模块
3.podSpec 依赖注入

BeeHive主要是把我们平时使用的所有的业务功能,以单一模块的形式进行解耦.

Module与Service

• 在BeeHive当中最重要的两个概念是Module 与Service，对应成中文可以翻译成“模块”与“服务”。Module是有生命周期的，其调用的时机是由事件来触发的，事件包括了系统事件，通用事件以及自定义事件。对于Module而言，BeeHive实现了队列化回调Module方法，开发人员可以给某个系统事件注册多个Module，BeeHive会依次调用不同的Module处理方法。Service则是单纯的代码实现模块，可以是实现某个功能的代码或业务代码，Service是没有生命周期的，在任何时候都可以调用。BeeHive借鉴了Spring的Service设计思想，Module与Service需要对接口进行抽象，通过接口来关联两个不同的模块，从而最大的降低代码的耦合性。

简单粗暴理解为 : 它们都是构建一个数据结构，然后根据这个数据结构设计它的生存环境，并让它在这个环境中按照一定的规律不停地运动，在它们的不停运动中设计一系列与环境或者与其他个体完成信息交换。

参照 Spring框架的设计理念

• 把Bean比做一场演出中的演员，Context就是这场演出的舞台背景，而Core应该就是演出的道具了。只有它们在一起才能具备能演出一场好戏的最基本的条件。当然有最基本的条件还不能使这场演出脱颖而出，还要它表演的节目足够精彩，这些节目就是Spring能提供的特色功能了。
• Spring解决了一个非常关键的问题，它可以让你把对象之间的依赖关系转而用配置文件来管理，也就是它的依赖注入机制。而这个注入关系在一个叫Ioc的容器中管理，

---

---

---

用自己的话总结 :

• BeeHive是一个把我们需要封装的业务逻辑单独抽离整理到一个Module中, 把业务逻辑从越来越臃肿的业务模块中抽离出来.
• Service是单纯的代码实现模块, 可以面向协议编程的思想来理解, Service告诉你这个Module里面有什么样的功能. Module注册了Service中的协议并实现
• 整个组件化的方案都是使用Cocoapod来管理的, 也就是podspec管理整个组件化的依赖注入.

---

与BeeHive组件化形成对比的方案

去Model化 : iOS应用架构谈 组件化方案

CTMediator : CTMediator的组件化方案

---

组件化的方案可以算是一个架构思想,这里需要使用哪种需结合项目业务的整体实现.

---

利用Beehive实现的Demo : LgMainProject

项目架构图

LgMainProject 
    |   
    | - LgMainProject (主项目)
    |
    | - LgComponents (组件)
            | 
            | _ LgFramework (远程仓库)
            | _ LgPublic (本地仓库)
            | _ LgUIKit (本地仓库)

模块思想 :

Module Class

项目框架 :

Demo框架

参考文档 :
蘑菇街、滴滴、淘宝、微信的组件化架构解析
3分钟让你的框架支持cocoapods,podspec文件讲解
蘑菇街 App 的组件化之路
BeeHive 框架实现原理分析
BeeHive官方源码