酝酿已久的 Hasor2

    自从2014年1月份更新了一个版本之后，Hasor的更新一直处于沉静状态。这段时间内因为工作变动、搬家等原因。导致Hasor的更新变慢了。 尽管这样，Hasor仍然在进行开发。新版Hasor，暂定名为 Hasor2。新版本变化非常大。

一、Hasor不再强制依赖Guice

    虽然Guice作为Hasor的默认DI引擎非常理想，但是Guice和Spring之间的协调变并不是很容易。在Hasor 1 中 Hasor提供了Bean注册机制，这个机制会交给位于更下层的Guice。正因为这样Spring作为一个独立的Bean容器其实是很难与Hasor融为一体。这也就使得Spring与Hasor的整合只能趋向于表面。

    于是新版的Hasor内部构建了一套全新的 Bean 绑定机制，通过这套机制Hasor有了自己的Bean注册API。所有注册的Bean信息最后都会通过 RegisterInfo 接口进行描述。新版Hasor正是通过这一点完成了不再强制依赖Guice的美好愿望。

    Hasor为什么前后这么纠结？

    Hasor 的架构其实是我在前任公司里做过的一个基础框架的开源实现。两套架构有很多相似的地方，但是完全不一样。同时Hasor也是为了技术练手开发的一个框架。

    开源之后，来自OSC的朋友问道，如何与Spring集成？其实从一开始来说Hasor并没有打算支持Spring。但是如果作为开源软件独立发展的话，Spring已经集成了众多优秀的框架。如果Hasor失去Spring，将意味着Hasor的生态圈变得非常狭窄因此Hasor开始在接下来的新版中尝试剥离Guice。不再强依赖某一个技术框架，Hasor还是尝试拥抱更多的选择。

二、Hasor2 弱化了模块概念，强调插件

    在Hasor1中Hasor还是十分强调（模块、组件化、生命周期、模块依赖）这些概念。从新版Hasor开始将不再强调这些概念，转而支持插件化。

    原因1（学习曲线陡峭）：在Hasor1中Hasor的扩展功能是以模块形式通过Module接口组织进入的，Module接口给出了init、start、stop三个方法。这三个方法分别对应了模块的三个生命周期。因为Hasor1强调模块开发，所以开发者在使用Hasor的时候除了要理解Hasor模块声明周期之外，还要了解Hasor依赖体系。这样一来开发Hasor的扩展功能的学习曲线比较大的。

    原因2（不实用）：作为Hasor的作者，在开发Hasor模块过程中我发现其实扩展Hasor主要还是围绕在Hasor的init阶段。start、stop两个阶段的设计基本是没什么用的。

    于是便有了HasorPlugin接口，通过HasorPlugin开简化Hasor模块的开发。到最后Hasor发展了14个内置插件，也都是通过HasorPlugin接口完成的，跟Module几乎没什么关系。这样一来原本设计的（模块体系、生命周期）最后通过简化的Plugin体系完全取缔了。

三、Hasor的目标重新定位

    最初打造Hasor的目的是想创造基础Java开发框架，这个框架上可以安装各种不同的功能模块。每个模块提供了不同的功能，通过这些这些功能组成一个适用于项目的开发环境。

    但是由于先天Hasor采用了模块化的概念进来，导致Hasor很多扩展都要围绕着模块进行，而这个模块概念又泛生出（依赖、生命周期）这样重量级的东西。因此很多朋友会直接联想起 OSGi。虽然Hasor已经力争与OSGi划清界限。但是依然有着重量级的影子在里面（虽然经过实践证明Module是一个鸡肋....）。

    Hasor还曾经试图打造一个容器框架，基于这个远景时想大力发展，Hasor的模块概念。通过加入ClassLoader等机制来完善Hasor本不完善的Moduel。这样一来Hasor从预期上更加趋向OSGi。如果继续发展下去，Hasor的价值就被做掉了。

    Hasor2 开始放弃Module，拥抱插件。重新回归轻量化基础框架行列。使用Hasor2，可以用过插件扩展期功能正如Hasor在一开始提到的“微内核+扩展”。

四、不再打造大平台

    其实Hasor的先前版本有一个特性就是任何一个基础组建包都会携带一大堆内置插件。这样的设计初衷是提供一个完备的基础环境，开发者引用了 Hasor 之后很多功能都可以通过 Hasor 直接提供。

    这样的想法本身就是有问题的，在实际开发中很难提供一个高度完备的开发环境。如果真的做到了会由于集成了太多东西而变得笨重，失去了轻量化、高灵活性的特征。

    新版Hasor扭转这种想法，只提供一个最轻量级的内核，所有扩展插件将会被全部被剥离出去。

五、更加透明、灵活

    Hasor 1 之前 Hasor 通过注解化的方式提供了很多便捷的插件，注解在Hasor1中是一个核心元素。推行注解化开发会给开发这带来很大的灵活性，但是由于注解的支持已经被深深植入Hasor内部。这样一来Hasor对于开发者相当于一个黑盒。使用Hasor提供的API虽然可以提供各种有用的插件，但是并不能帮助同学了解工作原理。这也就导致Hasor框架的可制定性大打折扣。

    Hasor2开始，只提供核心接口方法，内置插件将被剥离出去，成为Quice项目。如果有需要快速开发的同学可以直接使用这个项目来快速开发从而省去制定的麻烦。这样一来可以让更多同学可以对 Hasor 做出更多特色的制定，从而满足不同的业务场景需要。