lwkhehe的专栏

java IO 类层次图，以清晰明了的形式标明了java io中各种类的关系

这个效果是很不错的，自己写的！ 如有Bug，请联系499129880

SpringFramework 实际上是Expert One-on-One J2EE Design and<br>Development 一书中所阐述的设计思想的具体实现。在One-on-One 一书中，Rod<br>Johnson 倡导J2EE 实用主义的设计思想，并随书提供了一个初步的开发框架实现<br>（interface21 开发包）。而SpringFramework 正是这一思想的更全面和具体的体现。<br>Rod Johnson 在interface21 开发包的基础之上，进行了进一步的改造和扩充，使其发展<br>为一个更加开放、清晰、全面、高效的开发框架。<br>本文正是针对SpringFramework的开发指南，讲述了SpringFramework的设计思<br>想以及在开发中的实际使用。同时穿插了一些笔者在项目实作中的经验所得<br><br>

相对Hibernate和Apache OJB 等“一站式”ORM解决方案而言，ibatis 是一种“半<br>自动化”的ORM实现。<br>所谓“半自动”，可能理解上有点生涩。纵观目前主流的ORM，无论Hibernate 还是<br>Apache OJB，都对数据库结构提供了较为完整的封装，提供了从POJO 到数据库表的全<br>套映射机制。程序员往往只需定义好了POJO 到数据库表的映射关系，即可通过Hibernate<br>或者OJB 提供的方法完成持久层操作。程序员甚至不需要对SQL 的熟练掌握，<br>Hibernate/OJB 会根据制定的存储逻辑，自动生成对应的SQL 并调用JDBC 接口加以执<br>行。<br>大多数情况下（特别是对新项目，新系统的开发而言），这样的机制无往不利，大有一<br>统天下的势头。但是，在一些特定的环境下，这种一站式的解决方案却未必灵光。<br>在笔者的系统咨询工作过程中，常常遇到以下情况：<br>1． 系统的部分或全部数据来自现有数据库，处于安全考虑，只对开发团队提供几<br>条Select SQL（或存储过程）以获取所需数据，具体的表结构不予公开。<br>2． 开发规范中要求，所有牵涉到业务逻辑部分的数据库操作，必须在数据库层由<br>存储过程实现（就笔者工作所面向的金融行业而言，工商银行、中国银行、交<br>通银行，都在开发规范中严格指定）<br>3． 系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高<br>度优化的SQL语句（或存储过程）才能达到系统性能设计指标。<br>面对这样的需求，再次举起Hibernate 大刀，却发现刀锋不再锐利，甚至无法使用，<br>奈何？恍惚之际，只好再摸出JDBC 准备拼死一搏……，说得未免有些凄凉，直接使用JDBC<br>进行数据库操作实际上也是不错的选择，只是拖沓的数据库访问代码，乏味的字段读取操作<br>令人厌烦。<br>“半自动化”的ibatis，却刚好解决了这个问题。<br>这里的“半自动化”，是相对Hibernate等提供了全面的数据库封装机制的“全自动化”<br>ORM 实现而言，“全自动”ORM 实现了POJO 和数据库表之间的映射，以及SQL 的自动<br>生成和执行。而ibatis 的着力点，则在于POJO 与SQL之间的映射关系。也就是说，ibatis<br>并不会为程序员在运行期自动生成SQL 执行。具体的SQL 需要程序员编写，然后通过映<br>射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。<br>使用ibatis 提供的ORM机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，<br>这一层与通过Hibernate 实现ORM 而言基本一致，而对于具体的数据操作，Hibernate<br>会自动生成SQL 语句，而ibatis 则要求开发者编写具体的SQL 语句。相对Hibernate等<br>“全自动”ORM机制而言，ibatis 以SQL开发的工作量和数据库移植性上的让步，为系统<br>设计提供了更大的自由空间。作为“全自动”ORM 实现的一种有益补充，ibatis 的出现显<br>得别具意义。