Hasor 的思前想后

    这篇是承接《轻量级 Java 开发框架 设计》系列Blog文的后续文章，本文主要絮叨絮叨 关于 Hasor 的一些想法，欢迎大家品评。

    首先很抱歉各位关注这一些列文章的朋友，Hasor 这一系列文章更新速度并不是很快。其中主要是因为工作的缘故。

    关于 Hasor 我想有很多人并不了解这一款框架究竟是做什么的，我自己也承认在最初计划开发 Hasor 的时候也并没有想到会发展到何种程度。但是还是要感谢关注我的各位朋友，没有大家的支持和建议我永远不知道什么什么样的框架才是大家需要的。

    关于名子，其实名字并没有什么特别之处。只是觉得 Hasor 这个词的发音比较简单，而且朋友们也不需要花费精力去查英汉词典。我在起名字之时仅仅考虑的是易读，并没有参照任何典故或单词。

    Hasor 是一款 Java 开发框架，它又是 Guice 的一个增强工具。说它是工具有点狭义，所以还是称它专为 Guice 而生的开发框架把。

    起初打造 Hasor 是为了模块化开发，但随着开发的深入。越来越觉得，模块化开发是一个比较虚的概念（关于模块化开发我会另起一篇文章）。功能组件的模块化并不能真正的算作模块化开发，后来 Hasor 悄悄的改了名字。那么 Hasor 的定位究竟在哪里，成了我一个心中一直存在的问题！

    上个月公司开始组织旅游，也正好借机理清思绪好好思考一下 Hasor 的问题：

1. Hasor 是一个框架，而非一个工具包！
2. Hasor 是 Guice 的一个非常有力的补充！
3. Hasor 不是模块框架，也不是服务框架，更不是组建框架！
4. Hasor 是一种容器，这个容器可以方便的制定它的插件。从而通过插件支撑各类应用的开发！
5. 不可以重复制造轮子，优秀的代码可以直接 copy 过来（法律范畴内）！
6. 注解化开发，尽量使用注解代替繁重的 Xml 配置文件。
7. Hasor 必须要提供一个 Web 支持。
8. Hasor 可以为非 Web 类应用程序提供开发的支持。

    带着这些决定，Hasor 算是经过了重新定位以找到自己的目标。

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

对于一般 Java 应用程序的开发。

1.Hasor 被要求提供基础的 IoC/Aop 支持。
2.注解化 Aop 配置
3.Hasor 被要求提供 Xml 配置文件解析支持以方便业务程序对配置文件的需求。
4.提供事件开发机制。
5.要提供灵活的插件扩展机制。

对于 Web 应用程序开发。

1.前后端分离，后端主要负责业务以及数据提供。展示交给视图和前端。
2.不限制前端（客户端）的技术形式，任何前端框架都可以和 Hasor 整合。
3.所有开发性配置都采用注解形式，例如通过 @Aop 声明需要的拦截器、@Controller 声明Action 等等...
4.提供发布 Web Restful 服务，尽量贴近 JSR 311 标准。
5.Action 可以定义返回值处理方式。比方说返回一个字符串，而字符串值会被用作 请求转发。
6.可以注解方式配置 Servlet 和 Filter ，不需要考虑 容器（Tomcat）是否支持 Servlet 3.x的支持。
7.提供一个工具，方便从任意位置载入一个资源作为 Web请求响应。

对于 JDBC 方面。

1.放弃沉重的 ORM 思想，考虑使用轻量化  ORM 策略配置对象表记录映射。
2.提供5种事务隔离级别的支持：1.默认隔离级别、2.脏读、3.不可重复读、4.可重复读、5.同步事务。
3.提供 Spring 的7种事务传播行为控制。
4.提供基于 SQL 的数据库操作接口。
5.允许同时连接多个不同的数据库，作为数据源。
6.在不考虑 JTA 规范的情况下，支持多数据源事务控制。

----------------------------------------------------------------
目前的开发代码存放于（包括Demo程序）：
    Github：    https://github.com/zycgit/hasor
    git@OSC： http://git.oschina.net/zycgit/hasor

非常感谢您百忙之中抽出时间来看这一系博文。可以通过Maven 中央仓库网站  http://search.maven.org/ 搜索 Hasor 下载 hasor 的相关代码。