文档章节

Hasor 同 Spring OSGi 的比较及设计思想

哈库纳
 哈库纳
发布于 2013/12/27 22:01
字数 3149
阅读 4314
收藏 83
点赞 10
评论 27

    这篇是承接《轻量级 Java 开发框架 设计》系列Blog文的后续文章,本文将通过设计思想,实现方式上对比 Hasor Spring OSGi 三者。

    在开启本文之前我想用最简短的一段话介绍一下 Hasor 。

Hasor 它是一个 Java 应用开发框架,可以说任何类型 Java 项目都可以使用 Hasor 进行开发。 它的设计思想是通过为 Guice 构建了一个 Context 环境,并且配备了一套完善的插件扩展接口。剩下的所有功能都是由插件完成。

    很多朋友当看完上面这段介绍之后,脑海里便浮出 OSGi。

    当 Hasor 第一次登台 OSC 是通过一篇有关模块化开发的文章开始,在一开始便有人将 Hasor 与 OSGi 进行了对比。于是也有人觉得 Hasor 绝不会是轻量级的。

    况且 OSGi 是企业级模块化标准之一,而恰恰 Hasor 的首次亮相也是通过模块化概念进行阐述。这也难怪 Hasor 从一开始就和 OSGi 有着解不开的关系。

    直到我加入一个小组讨论中才发现,将 Hasor 看作是 OSGi 翻版的人并不是少数。虽然我已经极力的介绍过它的架构和一些功能设计。但是很多朋友依然还认为 Hasor 和 OSGi 比较相似。

    在设计 Hasor 之前我也研究过 OSGi ,其实从本质上 Hasor 和 OSGi 是根本不同的两个东西。

    我个人觉得,Hasor 的架构思想和 Spring 是基本一样的,都是在依赖注入控制反转基础上建立起的框架体系。而 Hasor 不同于 Spring 的是 Hasor 更注重插件接口,这样的设计其实是最小化 Hasor 的重要保证。

    因为我们知道现在的 Spring 已经不是几年前的 Spring ,它的功能逐渐变大增强,或许有些人认为 Spring 在某些领域已经不能被称之为轻量级了。我猜想这最主要的原因是项目依赖的 Jar 包太多了,动不动就几十上百兆。

    Hasor 在初期注重插件接口,在这一部分 Hasor 走在 Spring 前面。也正是通过这种方式 Hasor 才可以保证在将来功能增长时可以保证孑然一身,最轻化。

    即使是现在 Hasor 具备了三大模块,共计 14 个插件,累计 524 个类文件的时候,真正属于 Hasor 的核心部件仍然只有最初的 45 个类文件。在包括注释在内平均每个类文件不会超过 400 行。其余所有类都是 Hasor 的插件,而插件是可以被抛弃的。即使是未来的功能增长能促使 Hasor 更新核心类的地方也很难出现。

    因此我可以肯定的说 Hasor 本身是轻量级的!它绝不重!

--------------------------------------------------------------

1.OSGi 是一个插件平台

    OSGi 了解它的朋友都知道,OSGi 有着一个完善的模块化插件体系。OSGi 会为每个插件单独分配一个独立的 ClassLoader,并且 OSGi 还为每个插件提供了动态装载,卸载以及热部署的支持。

    如果你了解的更多会发现 OSGi 甚至可以从你指定的 URL 地址中自动更新插件版本。而且它还可以处理模块多种版本同时存在情况下的兼容问题。如果这还不算什么的话,OSGi 还会带给你更多惊喜。

2.OSGi 是一个服务平台

    在 OSGi 中每个插件都可以通过容器提供的接口向外发布服务。同时插件也可以使用其它插件发布的服务。而这一切都是通过 OSGi 连接点完成。

    OSGi 连接点的使用是插件与插件之间沟通的主要媒介,这一点在使用上有点类似“依赖注入”,不同于传统依赖注入的是 OSGi 当注入一个服务对象时候都会为这个服务对象包装一个代理层。正是有了这层代理层 OSGi 才可以完成热更新。同样,借助这层代理 OSGi 也提供了相同插件不同版本共存。

3.OSGi 是一个工业级的标准

    如果你对 OSGi 还有一点不清楚的话,我告诉你它是一个工业化的标准,一个真真正正的模块化开发框架。它的模块化体现到了方方面面。

    你可以不用理会你的插件是否会引发 OSGi 容器运行的不稳定,也不用担心其它插件会影响到你程序的运行。而这一切正式通过 OSGi 完善的版本号管理来提供的。

    正因为如此你可以在 OSGi 标准上同时让一万个人同时开发不同的插件,最后可以稳定的集成到一起。而这一切如果不是工业化的标准恐怕是很难实现的。也正因为如此 OSGi 给人感觉太重了。

4.OSGi 与 Hasor 对比

    如果说 Hasor 还有资格和 OSGi 对比的话,我只能说 Hasor 也有插件。Hasor 通过扩展插件来扩充自己的功能。而这一切,只是建立在所有插件都要求实现 Module 接口的前提下。

    Hasor 也提供了模块的依赖,这似乎让 Hasor 更加接近 OSGi 。可是 Hasor 模块依赖管理,其本质只是为所有插件提供一个初始化先后顺序的配置方式。所以在一开始 Hasor 与 OSGi 就有着本质的差别。

    OSGi 会为每个插件提供一个独立的 ClassLoader 。而 Hasor 要求所有插件类都必须可以在同一个 ClassLoader 下找到。即使 Hasor 的插件支持 独立 ClassLoader 这个功能恐怕也只能由一个 Hasor 插件在其插件上提供的“插件功能”。

5.Spring 与 Hasor 的相似

    轻量化 Java 开发框架 Spring 我觉得它绝对算得上轻量化,即使是现在我也认为 Spring 依然是轻量化框架中的娇娇者。

    Hasor 与 Spring 从天生就注定很像,因为 Hasor 与 Spring 的核心思想是一样的。都是基于依赖注入和控制反转来构建整个架构。它们俩都通过 Context 为整个应用程序构建基础运行环境,也都是在 Context 上通过 IoC/Aop 为应用程序提供基础支持。

6.Hasor 是基于注解开发,而非 Xml

    Hasor 与 Spring 不同的是 Spring 紧紧环抱 Xml 配置文件。而 Hasor 则主要基于注解开发。在一般情况下,使用 Hasor 开发应用程序不需要编写任何配置文件,它是绝对零配置的。

    不过当你例如需要连接数据库或者修改默认配置。也只好通过 Hasor 的配置文件进行配置了。除此之外您不需要通过配置文件注册 Bean、Action、事务等等开发性的东西。

    Hasor 的配置文件主要是留给业务系统的,我们往往在开发一个程序时经常会产生一些配置信息。一般情况下我们使用属性文件去承载,这是由于解析自定义 Xml 配置文件实在是繁琐且必要性不大。Hasor 提供了一种统一的方式读取自定义配置文件。

    这种方式使得开发者可以拥有 Xml 那种结构化的表述,同时还保留了属性文件那种简单方便的特性。您可以不编写任何代码直接从一个自定义配置文件中读取到配置信息。而它的读取方式却和读取属性文件一样。

    我猜想,实施人员会很喜欢这个特性。因为结构化的Xml 总比若干属性文件来的更加直观。即使是开发人员,也会从中得到很多快乐。

7.Hasor 小,轻,快

   Hasor 与 Spring 一样是一款轻量化框架,它甚至比 Spring 更加轻量。这一点不单单是从 Jar 包体积上体现。

    在 Hasor 中没有 Spring 那种庞大的配置文件映射解析系统。我曾经尝试开发一个与 Spring 相似的配置文件解析映射系统,当我完成了 300 个类规模的时候。我仅仅做到了Spring Beans、Spring Context两个组成部分的解析。在 Hasor 中有关配置文件解析的类文件只有 12 个类文件。代码总行数不过 1000 行,而这其中包括了 import 等元素。

    Hasor 没有开发 IoC.Aop 部分,这一部分转而是由 Google 公司出品的 Guice 工具提供。Guice 是一款轻量化 DI 工具。这个工具可以说只是 JSR-330 的一个标准实现,除此之外 Guice 别无它用。

    单单一个 Guice 是无法和 Spring 抗衡的,开发者如果想使用 Guice 去代替 Spring。也需要做很多工作之后才能完成迁移。这些工作当然不仅仅是代码上的改动。这主要是由于 Guice 本身缺少了 Spring Context 部分,而 Hasor 恰恰是在补充 Guice 确实的那部分。

    在 Guice 官网上我们可以看到 Guice 号称快过 Spring 1000 倍。我想这个数据差异应该不仅仅是启动速度的体现把。

    Guice 在对 Bean进行依赖注入时不会预先的知道都需要哪些属性需要注入,在它内部 Guice 使用了经典的 Visitor 模式当遇到 @Inject 时候才去构建依赖注入的对象。这种设计会比 Spring 从其内部庞大的 Bean 定义元信息中解析数据来的更加直接,更加迅速。同样的 Guice 也不需要通过容器管理 Bean 的生命周期,这也为创建 Bean 提供了大量宝贵的性能。

8.Hasor 设计思想

    Hasor 坚持走轻量化路线,努力的保持其核心最小化。这个目标和 JFinal 有些接近。但是当 Hasor 要想保持自己轻盈,又想壮大功能时。免不了会与目标发生冲突,毕竟支持一个功能最起码也是需要经过编码的。这是一个瓶颈,也可以说是一个软件的设计边界。

    许多开源软件最终都走到这一边界停下了自己的脚步,Hasor 试图踏出这一边界。所以 Hasor 最核心的问题是如何面对这个瓶颈。

    OSGi 的插件体系的确给了 Hasor 一些灵感。作为 OSGi 最成功的项目 Eclipse 而言,整个Eclipse 都是由插件堆砌起来的如果将 Eclipse 中所有插件全部剔除,您会发现这只能剩下一个 OSGi Context 程序。

    正是这个灵感,才促使 Hasor 有了一个突破口。

    假如 Hasor 的核心功能是 @Aop、@Event、@Controller、@Restful、@NeedCache、@Power.... 谁会晓得哪里是个头呢?

    一味的集成最后只能让 Hasor 走到轻量化框架的边缘,然后制住脚步等待后来者,最后与后来者一同埋葬在轻量化框架的坟场中。

    因此 Hasor 也采用 Context + Plugin 这种模式。重点放在 Plugin 接口如何设计而非 @Aop @Bean @Controller 的设计。

    Hasor 认为,插件是灵活的并且极不可靠。永远都有更加有效的 @Controller 来替代已存在的。因此 Hasor 当遇到 Web 时只会通过设计为其提供一个 Web 下的插件开发接口。这样一来所有 @Controller @Restful @Hessian @WebService @WebServlet @WebFilter 都可以插件形式在 Hasor 上运行。

    插件本身又不属于 Hasor 有了这样的保证,Hasor 才可以放心大胆的去走出瓶颈,突破轻量化框架的边界。而这一切到目前为止还很有成效。

    Hasor 目前包含了 Hasor-Core、Hasor-Web、Hasor-JDBC 三个部分,共计 14个插件,插件的数量仍在上升 Hasor 通过插件扩充自己的领域。也通过插件为开发者提供更加友好的开发体验。

    假如开发者不喜欢 Hasor 的 @Controller 开发者完全可以自己开发一个全新的将其取之。而 Hasor 本身却不会受到任何影响。

    这就是 Hasor ,一个基于 Guice 的轻量化框架。利用它你可以搭建自己的框架,利用它你可以整合诸多技术。

© 著作权归作者所有

共有 人打赏支持
哈库纳

哈库纳

粉丝 956
博文 89
码字总数 149803
作品 4
杭州
后端工程师
加载中

评论(27)

爱看书不识字
爱看书不识字
好东西,关于一下
哈库纳
哈库纳

引用来自“赵占涛”的评论

引用来自“哈库纳”的评论

引用来自“赵占涛”的评论

引用来自“魔眼神心”的评论

很喜欢这种context + 插件扩展思想,公司一直有人在做面向积木编程,也是类似的思想,关注hasor的发展~

面向积木?求解释

意思就是说,事先做好很多功能组件。每个组件就是一块积木。等到开发项目时候需要什么功能就把那个功能组件当成积木一样直接引用进来什么都不改。不搞框架集成。

你一定是个大神 关注一下你

谢谢关注,希望 hasor 带给你眼前一亮的感觉。哈哈
哈库纳
哈库纳

引用来自“赵占涛”的评论

引用来自“哈库纳”的评论

引用来自“赵占涛”的评论

引用来自“魔眼神心”的评论

很喜欢这种context + 插件扩展思想,公司一直有人在做面向积木编程,也是类似的思想,关注hasor的发展~

面向积木?求解释

意思就是说,事先做好很多功能组件。每个组件就是一块积木。等到开发项目时候需要什么功能就把那个功能组件当成积木一样直接引用进来什么都不改。不搞框架集成。

另一种理解就是 来一阵风就倒 哈哈。积木之间有没有螺丝固定?

如果是功能单一的组建一般是不需要螺丝去固定的。比方说 hasor 的那些插件,没有一个需要螺丝固定。都是引用进来就开始工作。是否需要螺丝固定还的看插件设计的是否完全独立。
赵占涛
赵占涛

引用来自“哈库纳”的评论

引用来自“赵占涛”的评论

引用来自“魔眼神心”的评论

很喜欢这种context + 插件扩展思想,公司一直有人在做面向积木编程,也是类似的思想,关注hasor的发展~

面向积木?求解释

意思就是说,事先做好很多功能组件。每个组件就是一块积木。等到开发项目时候需要什么功能就把那个功能组件当成积木一样直接引用进来什么都不改。不搞框架集成。

你一定是个大神 关注一下你
赵占涛
赵占涛

引用来自“哈库纳”的评论

引用来自“赵占涛”的评论

引用来自“魔眼神心”的评论

很喜欢这种context + 插件扩展思想,公司一直有人在做面向积木编程,也是类似的思想,关注hasor的发展~

面向积木?求解释

意思就是说,事先做好很多功能组件。每个组件就是一块积木。等到开发项目时候需要什么功能就把那个功能组件当成积木一样直接引用进来什么都不改。不搞框架集成。

另一种理解就是 来一阵风就倒 哈哈。积木之间有没有螺丝固定?
哈库纳
哈库纳

引用来自“赵占涛”的评论

引用来自“魔眼神心”的评论

很喜欢这种context + 插件扩展思想,公司一直有人在做面向积木编程,也是类似的思想,关注hasor的发展~

面向积木?求解释

意思就是说,事先做好很多功能组件。每个组件就是一块积木。等到开发项目时候需要什么功能就把那个功能组件当成积木一样直接引用进来什么都不改。不搞框架集成。
赵占涛
赵占涛

引用来自“魔眼神心”的评论

很喜欢这种context + 插件扩展思想,公司一直有人在做面向积木编程,也是类似的思想,关注hasor的发展~

面向积木?求解释
不会飞的猪
不会飞的猪
mark~
哈库纳
哈库纳

引用来自“魔眼神心”的评论

很喜欢这种context + 插件扩展思想,公司一直有人在做面向积木编程,也是类似的思想,关注hasor的发展~

谢谢关注,最近 Hasor 正在努力完善 JDBC 事务管理方面的缺陷。
魔眼神心
魔眼神心
很喜欢这种context + 插件扩展思想,公司一直有人在做面向积木编程,也是类似的思想,关注hasor的发展~
Eclipse 3.6稳定版发布:多平台的协奏曲

随着Eclipse 3.6最终RC版的发布,这个代号Helios(太阳神)的Eclipse年度版本再有不到一周的时间就将正式与我们见面。新版Eclipse增添大量实 用功能等在易用性、功能性方面的提升,在Eclipse...

walkerxk
2010/06/19
0
0
OSGI for C++ - 通往架构师之路

课程介绍 OSGI 技术是面向 Java 的动态模型系统。Java 圈子里有非常著名的一句话:OSGI - 架构师的天堂。换句话说,OSGI 能让软件开发变得更加容易! 值得庆幸的是,在 C++ 中也有类似的框架...

u011012932
04/16
0
0
探索 Eclipse 的 OSGi 控制台

从 V3.0 开始,Eclipse 通过选择开放服务网关协议(Open Services Gateway Initiative,OSGi)来替换先前版本中不稳定的 Eclipse 插件技术,从而实现了一次巨大飞跃。这次转变对于用户来说几...

银月光海
2014/04/11
0
1
OSGi与Maven、Eclipse PlugIn的区别

osgi 的框架 apache felix equinox osgi的bundle 、 maven 的 module 、 Eclipse 的 PlugIn 的区别。。。。 OSGi与Maven Maven也具有模块化系统的特征;但是它只是一个编译时工具,而不是运行...

owensliu
2014/11/04
0
0
android插件化-apkplug中OSGI服务基本原理-08

我们提供 apkplug 下OSGI使用demo 源码托管地址为 http://git.oschina.net/plug/OSGIService 一 OSGI与android Service 异同点 OSGI服务与android Service概念差不多也是Service ,Client 关系...

梁大帅
2014/05/12
0
0
SCA、SOA与OSGi概念浅析

基于组件的编程一直是软件业简化编程和提高效率和质量的一个重要方法,但是往往对于不同语言我们有不同的组件模型,从而需要不同的调用方式。SCA的目的是使用户在构建企业应用时有一个不再直...

loowj
2011/11/06
0
0
android利用apkplug框架实现主应用与插件通讯(传递任意对象)实现UI替换

时光匆匆,乍一看已半年过去了,经过这半年的埋头苦干今天终于有满血复活了。 利用apkplug框架实现动态替换宿主Activity中的UI元素,以达到不用更新应用就可以更换UI样式的目的。 先看效果图:...

梁大帅
2014/04/29
0
1
OSGi控制台在Eclipse插件开发中的妙用

OSGi的实现本身有一个控制台,提供插件的查看和管理功能。而Eclipse是基于OSGi的平台应用,这样我们可以使用这个控制台辅助进行插件的管理,调试等工作… 一、管理和诊断 从事插件开发的各位...

dollyn
2014/12/25
0
0
Hazelcast在OSGI中的classloading问题

前些日子在开发中用到了hazelcast,挺不错的一个DD支持分布式map,list等多种容器,而且实现了标准的JDK容器接口,实在是太赞了。和Spring配合使用,应该非常方便,测试的时候set一个标准的J...

gb314
2012/02/18
0
1
OSGi 4.3引入了Generics与Capabilities

在近日举办的EclipseCon 2011上,下一版的核心OSGi平台发布了最终草案,其文档将于不久之后发布。BJ Hargrave在演讲中介绍了OSGi 4.3的新特性,并且概述了它与旧版之间的差别。 泛型 意料之中...

墙头草
2011/04/01
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

about git flow

  昨天元芳做了git分支管理规范的分享,为了拓展大家关于git分支的认知,这里我特意再分享这两个关于git flow的链接,大家可以看一下。 Git 工作流程 Git分支管理策略   git flow本质上是...

qwfys
今天
2
0
Linux系统日志文件

/var/log/messages linux系统总日志 /etc/logrotate.conf 日志切割配置文件 参考https://my.oschina.net/u/2000675/blog/908189 dmesg命令 dmesg’命令显示linux内核的环形缓冲区信息,我们可...

chencheng-linux
今天
1
0
MacOS下给树莓派安装Raspbian系统

下载镜像 前往 树莓派官网 下载镜像。 点击 最新版Raspbian 下载最新版镜像。 下载后请,通过 访达 双击解压,或通过 unzip 命令解压。 检查下载的文件 ls -lh -rw-r--r-- 1 dingdayu s...

dingdayu
今天
1
0
spring boot使用通用mapper(tk.mapper) ,id自增和回显等问题

最近项目使用到tk.mapper设置id自增,数据库是mysql。在使用通用mapper主键生成过程中有一些问题,在总结一下。 1、UUID生成方式-字符串主键 在主键上增加注解 @Id @GeneratedValue...

北岩
今天
2
0
告警系统邮件引擎、运行告警系统

告警系统邮件引擎 cd mail vim mail.py #!/usr/bin/env python#-*- coding: UTF-8 -*-import os,sysreload(sys)sys.setdefaultencoding('utf8')import getoptimport smtplibfr......

Zhouliang6
今天
1
0
Java工具类—随机数

Java中常用的生成随机数有Math.random()方法及java.util.Random类.但他们生成的随机数都是伪随机的. Math.radom()方法 在jdk1.8的Math类中可以看到,Math.random()方法实际上就是调用Random类...

PrivateO2
今天
3
0
关于java内存模型、并发编程的好文

Java并发编程:volatile关键字解析    volatile这个关键字可能很多朋友都听说过,或许也都用过。在Java 5之前,它是一个备受争议的关键字,因为在程序中使用它往往会导致出人意料的结果。在...

DannyCoder
昨天
1
0
dubbo @Reference retries 重试次数 一个坑

在代码一中设置 成retries=0,也就是调用超时不用重试,结果DEBUG的时候总是重试,不是0吗,0就不用重试啊。为什么还是调用了多次呢? 结果在网上看到 这篇文章才明白 https://www.cnblogs....

奋斗的小牛
昨天
2
0
数据结构与算法3

要抓紧喽~~~~~~~放羊的孩纸回来喽 LowArray类和LowArrayApp类 程序将一个普通的Java数组封装在LowArray类中。类中的数组隐藏了起来,它是私有的,所以只有类自己的方法才能访问他。 LowArray...

沉迷于编程的小菜菜
昨天
1
0
spring boot应用测试框架介绍

一、spring boot应用测试存在的问题 官方提供的测试框架spring-boot-test-starter,虽然提供了很多功能(junit、spring test、assertj、hamcrest、mockito、jsonassert、jsonpath),但是在数...

yangjianzhou
昨天
8
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部