Hasor

本文 存属提醒我自己不要忘记的事情。也是向大家展示 Hasor 对于 JDBC 方面即将的又一个重大的进步。目前该方案还在实施中。 前段时间闲着没事分析了下 Spring JDBC ，觉得 Spring JDBC 的设计实在是太绝了，于是就拷贝了 Spring JDBC 的关键接口，然后开始了迁移工作，最后 Hasor - JDBC 问世。 可是 Hasor JDBC 至今仍有一个重大问题没有搞定，那就是事务控制。 虽然可以通过暴露 Connection 简单的加装一个 Aop 拦截器在配合 @Tar... 注解可以完成任务。但是我觉得我有点完美主义了。最近脑袋里一直都是 Spring 那套事务控制体系，我有种冲动在 Hasor 中重新实现这一套事务控制体系。 简介一下 Spring 事务方面的内容，Spring 对于事务方面支持 7种事务传播属性。我用这个接口表示它们： /** * 事务传播属性 * @version : 2013-10-30 * @author 赵永春(zyc@hasor.net) */ public enum TransactionBehavior { /** * 加入已有事务 * <p><i><b>释意</b></i>：尝试加入已经存在的事务中，如果没有则开启一个新的事务。*/ PROPAGATION_REQUIRED, /** * 独立事务 * <p><i

这篇是承接《 轻量级 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