说实话听说起【组件化架构】这个词汇还是在网上不小心看到的,在细看各种解释,发现就是Java的多工程联编,当然它也有它特有的思想成份在里面。不知道是谁造出来的,以前我们管它叫【模块化】,毕竟组件和模块从专业词汇上还是不同意思,而很多项目也是由组件组成的模块构成的。
下面简单说说它们的区别
组件化和模块化的价值都在于分治,组件以前是特指UI,现在是把具有某个单功能的项目也叫组件,比如网络,缓存等。而模块化侧重于将一系列单功能组成的多功能具有一定业务流程属性的单元,一组相关的组件可以定义成一个模块。
而我们做开发的是离不开业务,离不开产品流程的,所以说其实不用纠结组件化和模块化,有人说把项目皆组件的原则来设计,如果要较真你还真分不出它是组件还是模块!
什么组件化也好,模块化也好都只是一个思想,不是特定在某个语言、某个领域!就是解决大项目的臃肿,使大项目变成小项目,便于开发、维护,并使其能尽量复用达到组件的效果!(我相信大家口中组件化架构在实际搭建过程中,有相当一部分并非可以复用的组件而更像模块)!所以我认为组件和模块搭配使用才最好,能组件的咱就组件。说到底它就是一种思想!
这个东西就跟MVC一样很简单也很多变,简单点就是把工程拆拆拆,拆成相对独立单元便于自己测试、维护,也便于给别人使用等等(mvc的很多好处都可以用在它身上,不过这2个不是一个层级,不冲突)!而多变就是每人、每公司都可以不同!
不是说我们老早就开始设计什么组件化架构了,这个也是在工作中不断演变而来的,下面说下我在工作中怎么由无到有的来设计这个架构,当然这也是走一步改一步的!最后会把demo放上来,demo更多的是对本地仓库代码的管理!
我是11年开始从事移动端的,最早也是项目小而多,导致负责的项目很难维护,比如手里有3个都差不多的项目(毕竟一个公司做的东西应该都是相似的),如果突然发现一个改动比较多的bug,怎么办?以前最好的办法就是改一个,然后拷贝两份给另外的工程!
后来随着工作经验的积累开始将相同的、核心的拆成一个core工程,然后将core工程拖拉到主工程里面配置,才能解决这个问题。(我以前做过Android,Android的eclipse可以很简单的工程联编) 本来以为很好了,后来出来了CocoaPods就用更好的工具来管理它!但是当时也就2、3个工程组成一个大工程。没什么稀奇是吧!
后来接手的时候也是一个大工程,里面代码多的看的头疼,因为需求使这个项目需要拷贝近几十份来给客户,而每个项目都大同小异,模块也只是位置变变或者有点差异,当时也是欲哭无泪,在这种情况下不用想大家也知道了要模块化啦,进而把能封装的组件化,当然模块依然还是存在的。
所以需求场景造就项目架构的演变!
好了,说了点自己项目架构演变的过程,简单不废话!下面就是demo
demo中的组件交互用的是MGJRouter(这个不知道有没有人实际使用,我跑了下有点问题,然后就基于它修改啦。具体地址JDRouter)更改的,自己项目用的是配置文件,当然其核心原理都是有一个交互中心(单例滴),有人叫中间件!
GitHub地址:JDComponentBased