各种框架运行原理以及相关知识点

 

Struts2

Struts2是一个基于MVC设计模式的Web应用框架，它本质上相当于一个servlet，在MVC设计模式中，Struts2作为控制器(Controller)来建立模型与视图的数据交互。Struts 2是Struts的下一代产品，是在 struts 1和WebWork的技术基础上进行了合并的全新的Struts 2框架。其全新的Struts 2的体系结构与Struts 1的体系结构差别巨大。Struts 2以WebWork为核心，采用拦截器的机制来处理用户的请求，这样的设计也使得业务逻辑控制器能够与ServletAPI完全脱离开，所以Struts 2可以理解为WebWork的更新产品。虽然从Struts 1到Struts 2有着太大的变化，但是相对于WebWork，Struts 2的变化很小。

Struts 2发展历史
编辑
经过六年多的发展，Struts1已经成为了一个高度成熟的框架，不管是稳定性还是可靠性都得到了广泛的证明。市场占有率超过20%，拥有丰富的开发人群，几乎已经成为了事实上的工业标准。但是随着时间的流逝，技术的进步，Struts1的局限性也越来越多地暴露出来，并且制约了Struts1的继续发展。
对于Struts1框架而言，由于与JSP/Servlet耦合非常紧密，因而导致了一些严重的问题。首先，Struts1支持的表现层技术单一。由于Struts1出现的年代比较早，那个时候没有FreeMarker、Velocity等技术，因此它不可能与这些视图层的模版技术进行整合。其次，Struts1与Servlet API的严重耦合，使应用难于测试。最后，Struts1代码严重依赖于Struts1 API，属于侵入性框架。
从目前的技术层面上看，出现了许多与Struts1竞争的视图层框架，比如JSF、Tapestry和spring MVC等。这些框架由于出现的年代比较近，应用了最新的设计理念，同时也从Struts1中吸取了经验，克服了很多不足。这些框架的出现也促进了Struts的发展。
Struts已经分化成了两个框架：第一个是在传统的Struts1的基础上，融合了另外的一个优秀的Web框架WebWork的Struts2。Struts 2虽然是在Struts1的基础上发展起来的，但是实质上是以WebWork为核心的。Struts2为传统的Struts1注入了WebWork的先进的设计理念，统一了Struts1和WebWork两个框架。
Struts1分化出来的另外一个框架是Shale。这个框架远远超出了Struts1原有的设计思想，与原有的Struts1关联很少，使用了全新的设计思想。Shale更像一个新的框架而不是Struts1的升级。
Struts 2工作原理
编辑
Struts 2的工作原理图：
Struts 2体系结构
编辑
应用流程注解
当Web容器收到请求（HttpServletReques
t）它将请求传递给一个标准的的过滤链包括（ActionContextCleanUp）过滤器。
经过Other filters(SiteMesh ,etc)，需要调用FilterDispatcher核心控制器，然后它调用ActionMapper确定请求哪个Action，ActionMapper返回一个收集Action详细信息的ActionMaping对象。
FilterDispatcher将控制权委派给ActionProxy,ActionProxy调用配置管理器(ConfigurationManager) 从配置文件中读取配置信息(struts.xml)，然后创建ActionInvocation对象。
ActionInvocation在调用Action之前会依次的调用所用配置拦截器（Interceptor N）一旦执行结果返回结果字符串ActionInvocation负责查找结果字符串对应的(Result）然后执行这个Result Result会调用一些模版（JSP）来呈现页面。
拦截器(Interceptor N)会再被执行（顺序和Action执行之前相反）最后响应(HttpServletResponse)被返回在web.xml中配置的那些过滤器和（核心控制器）（FilterDispatcher）。
Struts 2技术改进
编辑
Struts 2对Struts1进行了巨大的改进。主要表现在如下几个方面：
在Action的实现方面
Struts1要求必须统一扩展自Action类，而Struts2中可以是一个POJO。
线程模型方面
Struts1的Action是单实例的，一个Action的实例处理所有的请求。Struts 2的Action是一个请求对应一个实例（每次请求时都新new出一个对象），没有线程安全方面的问题。
Servlet依赖方面
Struts1的Action依赖于Servlet API，比如Action的execute方法的参数就包括request和response对象。这使程序难于测试。Struts2中的Action不再依赖于Servlet API，有利于测试，并且实现TDD。
封装请求参数
Struts1中强制使用ActionForm对象封装请求的参数。Struts2可以选择使用POJO类来封装请求的参数，或者直接使用Action的属性。
表达式语言方面
Struts1中整合了EL，但是EL对集合和索引的支持不强，Struts2整合了OGNL（Object Graph NavigationLanguage）。
绑定值到视图技术
Struts1使用标准的JSP，Struts2使用“ValueStack”技术。
类型转换
Struts1中的ActionForm基本使用String类型的属性。Struts2中使用OGNL进行转换，可以更方便的使用。
Struts1中支持覆盖validate方法或者使用Validator框架。Struts2支持重写validate方法或者使用XWork的验证框架。
Action执行控制的对比
Struts1支持每一个模块对应一个请求处理，但是模块中的所有Action必须共享相同的生命周期。Struts2支持通过拦截器堆栈为每一个Action创建不同的生命周期。
拦截器的应用
拦截器，在AOP（Aspect-Oriented Programming）中用于在某个方法或字段被访问之前，进行拦截然后在之前或之后加入某些操作。拦截是AOP的一种实现策略。
在Webwork的中文文档的解释为——拦截器是动态拦截Action调用的对象。它提供了一种机制可以使开发者可以定义在一个action执行的前后执行的代码，也可以在一个action执行前阻止其执行。同时也是提供了一种可以提取action中可重用的部分的方式。
谈到拦截器，还有一个词大家应该知道——拦截器链（Interceptor Chain，在Struts 2中称为拦截器栈Interceptor Stack）。拦截器链就是将拦截器按一定的顺序联结成一条链。在访问被拦截的方法或字段时，拦截器链中的拦截器就会按其之前定义的顺序被调用。
1.拦截器的实现原理：
大部分时候，拦截器方法都是通过代理的方式来调用的。Struts 2的拦截器实现相对简单。当请求到达Struts 2的ServletDispatcher时，Struts 2会查找配置文件，并根据其配置实例化相对的拦截器对象，然后串成一个列表（list），最后一个一个地调用列表中的拦截器。
2.拦截器的配置
Struts 2已经为您提供丰富多样的，功能齐全的拦截器实现。大家可以至struts2的jar包内的struts-default.xml查看关于默认的拦截器与拦截器链的配置。
在struts.xml文件中定义拦截器，拦截器栈：


<package name="my" extends="struts-default" namespace="/manage">
<interceptors>
<!-- 定义拦截器 -->
<interceptor name="拦截器名" class="拦截器实现类"/>
<!-- 定义拦截器栈 -->
<interceptor-stack name="拦截器栈名">
<interceptor-ref name="拦截器一"/>
<interceptor-ref name="拦截器二"/>
</interceptor-stack>
</interceptors>
......
</package>
Struts 2对比
编辑
Struts和Webwork同为服务于Web的一种MVC框架，从某种程度上看，Struts2是从WebWork2上升级得到的。甚至Apache的官方文档也讲：WebWork2到Struts2是平滑的过渡。我们甚至也可以说Struts2就是WebWork2.3而已。在很多方面Struts仅仅是改变了WebWork下的名称。Struts2对应的有自己的标签，并且功能强大。Webwork也有自己的标签。在2005年12月，WebWork与Struts Ti决定合并， 在此同时， Struts Ti 改名为 Struts Action Framework 2.0,成为Struts真正的下一代。
Struts 2基类
编辑
Struts 2标准返回值
ActionSupport基类中定义了五个标准的返回值 ，当然我们可以自己随意定义返回的名字
String SUCCESS = "success"; //默认是 SUCCESS 类型
String NONE = "none";
String ERROR = "error";
String INPUT = "input";
String LOGIN = "login";
Struts 2方法
ActionSupport基类定义了了一些方法，程序员自己写的action如果继承了ActionSupport基类，就可以应用这些方法，很方便解决一些问题。
一些比较常用的方法：
getText(String aTextName);//国际化用到
...//getText(String aTextName)的重载方法
addActionMessage(String aMessage);
addFieldError(String fieldName, String errorMessage);
//校验失败后返回给客户端的信息，struts2 标签<s:fielderror />可以取得
addActionError(String anErrorMessage);
Struts 2Result Type
编辑
在默认时，<result>标签的type属性值是“dispatcher”（实际上就是转发，forward）。开发人员可以根据自己的需要指定不同的类型，如redirect、stream等。如下面代码所示：
<result name="save" type="redirect">
/result.jsp
</result>
这此result-type可以在struts2-core-2.0.11.1.jar包或struts2源代码中的struts-default.xml文件中找到，在这个文件中找到<result-types>标签，所有的result-type都在里面定义了。代码如下：
<result-types>
<result-type name="chain" class="com.opensymphony.xwork2.ActionChainResult"/>
<result-type name="dispatcher" class="org.apache.struts2.dispatcher.ServletDispatcherResult" default="true"/>
<result-type name="freemarker" class="org.apache.struts2.views.freemarker.FreemarkerResult"/>
<result-type name="httpheader" class="org.apache.struts2.dispatcher.HttpHeaderResult"/>
<result-type name="redirect" class="org.apache.struts2.dispatcher.ServletRedirectResult"/>
<result-type name="redirectAction" class="org.apache.struts2.dispatcher.ServletActionRedirectResult"/>
<result-type name="stream" class="org.apache.struts2.dispatcher.StreamResult"/>
<result-type name="velocity" class="org.apache.struts2.dispatcher.VelocityResult"/>
<result-type name="xslt" class="org.apache.struts2.views.xslt.XSLTResult"/>
<result-type name="plainText" class="org.apache.struts2.dispatcher.PlainTextResult" />
<!-- Deprecated name form scheduled for removal in Struts 2.1.0. The camelCase versions are preferred. See ww-1707 -->
<result-type name="redirect-action" class="org.apache.struts2.dispatcher.ServletActionRedirectResult"/>
<result-type name="plaintext" class="org.apache.struts2.dispatcher.PlainTextResult" />
</result-types>
Struts 2dispatcher
用来转向页面，通常处理JSP

org.apache.struts2.dispatcher.ServletDispatcherResult
Struts 2freemaker
处理FreeMarker模板
org.apache.struts2.views.freemarker.FreemarkerResult
Struts 2httpheader
控制特殊HTTP行为的结果类型
?
org.apache.struts2.dispatcher.HttpHeaderResult
Struts 2stream
向浏览器发送InputStream对象，通常用来处理文件下载，还可用于返回AJAX数据

org.apache.struts2.dispatcher.StreamResult
StreamResult等价于在Servlet中直接输出Stream流。这种Result被经常使用于输出图片、文档等二进制流到 客户端。通过使用StreamResult，我们只需要在Action中准备好需要输出的InputStream即可。
配置：

<result name="success" type="stream">
<param name="contentType">image/jpeg</param>
<param name="inputName">imageStream</param>
<param name="contentDisposition">filename="document.pdf"</param>
<param name="bufferSize">1024</param>
</result>
同时，StreamResult支持许多参数，对输出的Stream流进行参数控制。
Struts 2velocity
处理Velocity模板

org.apache.struts2.dispatcher.VelocityResult
随着模板技术的越来越流行，使用Freemarker或者Velocity模板进行View层展示的开发者越来越多。Struts2同样为模板作为Result做出了支持。由于模板的显示需要模板（Template）与数据（Model）的紧密配合，所以在Struts2中，这两个Result的主要工作是为模板准备数据。
Struts 2xslt
处理XML/XLST模板

org.apache.struts2.views.xslt.XSLTResult
Struts 2plainText
显示原始文件内容，例如文件源代码

org.apache.struts2.dispatcher.PlainTextResult
Struts 2chain
用来处理Action链

com.opensymphony.xwork2.ActionChainResult
chain其实只是在一个action执行完毕之后，forward到另外一个action，所以他们之间是共享HttpServletRequest的。在使用chain作为Result时，往往会配合使用ChainingInterceptor。ChainingInterceptor的作用是在Action直接传递数据。事实上，源Action中ValueStack的数据会被做一次Copy，这样，2个Action中的数据都在ValueStack中，使得对于前台来说，通过ValueStack来取数据，是透明而共享的。比如说，一张页面中，你可能有许多数据要显示，而某些数据的获取方式可能被很多不同的页面共享（典型来说，“推荐文章”这个小栏目的数据获取，可能会被很多页面所共享）。这种情况下，可以把这部分逻辑抽取到一个独立Action中，并使用chain，将这个Action与主Action串联起来。这样，最后到达页面的时候，页面始终可以得到每个Action中的数据。
从实战上讲，使用chain作为Result也的确存在着上面所说的许多问题，我个人也是非常不推崇滥用这种Result。尤其是，对于使用Spring和Hibernate的朋友来说，如果你开启OpenSessionInView模式，那么Hibernate的session是跟随HttpServletRequest的，所以session在整个action链中共享。这会为我们的编程带来极大的麻烦。因为我们知道Hibernate的session会保留一份一级缓存，在action链中，共享一级缓存无疑会为你的调试工作带来很大的不方便。
所以，谨慎使用chain作为你的Result，应该成为一条最佳实践。
Struts 2redirect
重定向到一个URL
?
1

org.apache.struts2.dispatcher.ServletRedirectResult
如果你在Action执行完毕后，希望执行另一个Action，有2种方式可供选择。一种是forward，另外一种是redirect。有关forward和redirect的区别，这里我就不再展开，这应该属于Java程序员的基本知识。在Struts2中，分别对应这两种方式的Result，就是chain和redirect。
先来谈谈redirect，既然是重定向，那么源地址与目标地址之间是2个不同的HttpServletRequest。所以目标地址将无法通过ValueStack等Struts2的特性来获取源Action中的数据。
同时，Redirect的Result支持在配置文件中，读取并解析源Action中ValueStack的值，并成为参数传递到Redirect的地址中。
Struts 2redirectAction
重定向到一个Action
?
1

org.apache.struts2.dispatcher.ServletActionRedirectResult
Struts 2区别比较
编辑
redirect和redirectAction chain的区别
struts2中关于result的返回类型一般我们是转发到一个jsp页面或者是html页面等，但是struts2中的result的返回类型还有redirect,redirectAction,chain。对于这三种返回类型之间肯定是有区别的，下面我们来看看关于redirect redirectAction chain这三种struts2的返回类型之间的区别。当使用type=“redirectAction” 或type=“redirect”提交到一个action并且需要传递一个参数时。这里是有区别的：使用type=“redirectAction”时，结果就只能写Action的配置名，不能带有后缀：“.action”
Xml代码
?

<action name="Login" class="steven.actions.LoginAction">
<result name="success" type="redirectAction">User?u_id=${loginBean.u_id}</result>
</action>
使用type=“redirect”时，结果应是action配置名+后缀名
Xml代码
?

<action name="Login" class="steven.actions.LoginAction">
<result name="success" type="redirect">User.action?u_id=${loginBean.u_id}</result>
</action>
redirect:action处理完后重定向到一个视图资源（如：jsp页面），请求参数全部丢失，action处理结果也全部丢失。
redirect-action:action处理完后重定向到一个action，请求参数全部丢失，action处理结果也全部丢失。
chain:action处理完后转发到一个action，请求参数全部丢失，action处理结果不会丢失。
Struts 2出现漏洞
编辑
曝出高危安全漏洞
Struts2曝出2个高危安全漏洞，一个是使用缩写的导航参数前缀时的远程代码执行漏洞，另一个是使用缩写的重定向参数前缀时的开放式重定向漏洞。这些漏洞可使黑客取得网站服务器的“最高权限”，从而使企业服务器变成黑客手中的“肉鸡”。
解决措施
Apache Struts团队已发布了最新的Struts 2.3.15.1，修复了上述漏洞，建议采用Struts 2.0至Struts 2.3的网站开发者尽快升级至最新版。[1]
带来影响
据乌云平台漏洞报告，淘宝、京东、腾讯等大型互联网厂商均受此影响，而且漏洞利用代码已经被强化，可直接通过浏览器的提交对服务器进行任意操作并获取敏感内容。Struts漏洞影响巨大，受影响站点以电商、银行、门户、政府居多，而且一些自动化、傻瓜化的利用工具开始出现，填入地址可直接执行服务器命令，读取数据甚至直接关机等操作。[1]
瑞星安全专家介绍，本次曝出的2个漏洞是由于缩写的导航和重定向前缀“action:”、 “redirect:”、 “redirectAction:”造成的。瑞星安全专家表示，由于这些参数前缀的内容没有被正确过滤，导致黑客可以通过漏洞执行命令，获取目标服务器的信息，并进一步取得服务器最高控制权。届时，被攻击网站的数据库将面临全面泄密的威胁，同时黑客还可以通过重定向漏洞的手段，对其他网民进行钓鱼攻击或挂马攻击。

 

 

=====================================、

 

Hbase框架
HBase是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的BigTable建模，实现的编程语言为Java。它是Apache软件基金会Hadoop项目的一部分，运行于HDFS文件系统之上，为Hadoop提供类似于BigTable规模的服务。HBase在列上实现了BigTable论文提到的压缩算法、内存操作和布隆过滤器。HBase的表能够作为MapReduce任务的输入和输出，可以通过Java API来存取数据，也可以通过REST、Avro或者Thrift的API来访问。HBase虽然性能有显著的提升，但还不能直接取代SQL数据库。现今它已经应用于多个数据驱动型网站。

快速导航
关系表知乎精选
概况
知乎精选最新
目
录
1基本介绍
2主要模型
3访问接口
4存储格式
5相关文档
1 基本介绍 编辑
HBase–HadoopDatabase，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群。

与YonghongZ-DataMart等商用大数据产品不同，HBase是GoogleBigtable的开源实现，类似GoogleBigtable利用GFS作为其文件存储系统，HBase利用HadoopHDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用HadoopMapReduce来处理HBase中的海量数据；GoogleBigtable利用Chubby作为协同服务，HBase利用Zookeeper作为对应。[1]

上图描述HadoopEcoSystem中的各层系统其中,HBase位于结构化存储层，HadoopHDFS为HBase提供了高可靠性的底层存储支持，HadoopMapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover机制。

此外，Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。

2 主要模型 编辑
主要讨论逻辑模型和物理模型

（1）逻辑模型

Hbase的名字的来源是Hadoopdatabase，即hadoop数据库。

主要是从用户角度来考虑，即如何使用Hbase。

（2）物理模型

主要从实现Hbase的角度来讨论

3 访问接口 编辑
1.NativeJavaAPI，最常规和高效的访问方式，适合HadoopMapReduceJob并行批处理HBase表数据

2.HBaseShell，HBase的命令行工具，最简单的接口，适合HBase管理使用

3.ThriftGateway，利用Thrift序列化技术，支持C++，PHP，Python等多种语言，适合其他异构系统在线访问HBase表数据

4.RESTGateway，支持REST风格的HttpAPI访问HBase,解除了语言限制

5.Pig，可以使用PigLatin流式编程语言来操作HBase中的数据，和Hive类似，本质最终也是编译成MapReduceJob来处理HBase表数据，适合做数据统计

6.Hive，当前Hive的Release版本尚没有加入对HBase的支持，但在下一个版本Hive0.7.0中将会支持HBase，可以使用类似SQL语言来访问HBase

HBase数据模型Table&ColumnFamily

RowKey Timestamp ColumnFamily
URI Parser
r1 t3 url=http:// title=
t2 host=com
t1
r2 t5 url=http:// content=每天…
t4 host=com
?RowKey:行键，Table的主键，Table中的记录默认按照RowKey升序排序

?Timestamp:时间戳，每次数据操作对应的时间戳，可以看作是数据的versionnumber

?ColumnFamily：列簇，Table在水平方向有一个或者多个ColumnFamily组成，一个ColumnFamily中可以由任意多个Column组成，即ColumnFamily支持动态扩展，无需预先定义Column的数量以及类型，所有Column均以二进制格式存储，用户需要自行进行类型转换。

Table&Region

当Table随着记录数不断增加而变大后，会逐渐分裂成多份splits，成为regions，一个region由[startkey,endkey)表示，不同的region会被Master分配给相应的RegionServer进行管理：

-ROOT-&&.META.Table

HBase中有两张特殊的Table，-ROOT-和.META.

?.META.：记录了用户表的Region信息，.META.可以有多个regoin

?-ROOT-：记录了.META.表的Region信息，-ROOT-只有一个region

?Zookeeper中记录了-ROOT-表的location

Client访问用户数据之前需要首先访问zookeeper，然后访问-ROOT-表，接着访问.META.表，最后才能找到用户数据的位置去访问，中间需要多次网络操作，不过client端会做cache缓存。

MapReduceonHBase

在HBase系统上运行批处理运算，最方便和实用的模型依然是MapReduce，如下图：

HBaseTable和Region的关系，比较类似HDFSFile和Block的关系，HBase提供了配套的TableInputFormat和TableOutputFormatAPI，可以方便的将HBaseTable作为HadoopMapReduce的Source和Sink，对于MapReduceJob应用开发人员来说，基本不需要关注HBase系统自身的细节。

HBase系统架构

ClientHBaseClient使用HBase的RPC机制与HMaster和HRegionServer进行通信，对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC

1Zookeeper

ZookeeperQuorum中除了存储了-ROOT-表的地址和HMaster的地址，HRegionServer也会把自己以Ephemeral方式注册到Zookeeper中，使得HMaster可以随时感知到各个HRegionServer的健康状态。此外，Zookeeper也避免了HMaster的单点问题，见下文描述

HMaster

HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的MasterElection机制保证总有一个Master运行，HMaster在功能上主要负责Table和Region的管理工作：

1.管理用户对Table的增、删、改、查操作

2.管理HRegionServer的负载均衡，调整Region分布

3.在RegionSplit后，负责新Region的分配

4.在HRegionServer停机后，负责失效HRegionServer上的Regions迁移

HRegionServer

HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。

HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，HRegion中由多个HStore组成。每个HStore对应了Table中的一个ColumnFamily的存储，可以看出每个ColumnFamily其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个ColumnFamily中，这样最高效。

HStore存储是HBase存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。MemStore是SortedMemoryBuffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBaseI/O的高性能。当StoreFilesCompact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前RegionSplit成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。下图描述了Compaction和Split的过程：

在理解了上述HStore的基本原理后，还必须了解一下HLog的功能，因为上述的HStore在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，因此一旦HRegionServer意外退出，MemStore中的内存数据将会丢失，这就需要引入HLog了。每个HRegionServer中都有一个HLog对象，HLog是一个实现WriteAheadLog的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中（HLog文件格式见后续），HLog文件定期会滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）。当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应region的目录下，然后再将失效的region重新分配，领取到这些region的HRegionServer在LoadRegion的过程中，会发现有历史HLog需要处理，因此会ReplayHLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。

4 存储格式 编辑
HBase中的所有数据文件都存储在HadoopHDFS文件系统上，主要包括上述提出的两种文件类型：

1.HFile，HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile

2.HLogFile，HBase中WAL（WriteAheadLog）的存储格式，物理上是Hadoop的SequenceFile

HFile

下图是HFile的存储格式：

首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。正如图中所示的，Trailer中有指针指向其他数据块的起始点。FileInfo中记录了文件的一些Meta信息，例如：AVG_KEY_LEN,AVG_VALUE_LEN,LAST_KEY,COMPARATOR,MAX_SEQ_ID_KEY等。DataIndex和MetaIndex块记录了每个Data块和Meta块的起始点。

DataBlock是HBaseI/O的基本单元，为了提高效率，HRegionServer中有基于LRU的BlockCache机制。每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询。每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成,Magic内容就是一些随机数字，目的是防止数据损坏。后面会详细介绍每个KeyValue对的内部构造。

HFile里面的每个KeyValue对就是一个简单的byte数组。但是这个byte数组里面包含了很多项，并且有固定的结构。我们来看看里面的具体结构：

开始是两个固定长度的数值，分别表示Key的长度和Value的长度。紧接着是Key，开始是固定长度的数值，表示RowKey的长度，紧接着是RowKey，然后是固定长度的数值，表示Family的长度，然后是Family，接着是Qualifier，然后是两个固定长度的数值，表示TimeStamp和KeyType（Put/Delete）。Value部分没有这么复杂的结构，就是纯粹的二进制数据了。

HLogFile

上图中示意了HLog文件的结构，其实HLog文件就是一个普通的HadoopSequenceFile，SequenceFile的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括sequencenumber和timestamp，timestamp是“写入时间”，sequencenumber的起始值为0，或者是最近一次存入文件系统中sequencenumber。

HLogSequeceFile的Value是HBase的KeyValue对象，即对应HFile中的KeyValue，可

 

 

======================================================

Spring框架
一、 IoC(Inversion of control): 控制反转
1、IoC：
概念：控制权由对象本身转向容器；由容器根据配置文件去创建实例并创建各个实例之间的依赖关系
核心：bean工厂；在Spring中，bean工厂创建的各个实例称作bean
二、AOP(Aspect-Oriented Programming): 面向方面编程
1、 代理的两种方式：
静态代理：
? 针对每个具体类分别编写代理类；
? 针对一个接口编写一个代理类；
动态代理：
针对一个方面编写一个InvocationHandler，然后借用JDK反射包中的Proxy类为各种接口动态生成相应的代理类
2、 AOP的主要原理：动态代理

 

Spring工作原理
Spring 已经用过一段时间了，感觉Spring是个很不错的框架。内部最核心的就是IOC了，
动态注入，让一个对象的创建不用new了，可以自动的生产，这其实就是利用java里的反射
反射其实就是在运行时动态的去创建、调用对象，Spring就是在运行时，跟xml Spring的配置
文件来动态的创建对象，和调用对象里的方法的 。
Spring还有一个核心就是AOP这个就是面向切面编程，可以为某一类对象 进行监督和控制（也就是
在调用这类对象的具体方法的前后去调用你指定的 模块）从而达到对一个模块扩充的功能。这些都是通过
配置类达到的。
Spring目的：就是让对象与对象（模块与模块）之间的关系没有通过代码来关联，都是通过配置类说明
管理的（Spring根据这些配置 内部通过反射去动态的组装对象）
要记住：Spring是一个容器，凡是在容器里的对象才会有Spring所提供的这些服务和功能。
Spring里用的最经典的一个设计模式就是：模板方法模式。（这里我都不介绍了，是一个很常用的设计模式）
Spring里的配置是很多的，很难都记住，但是Spring里的精华也无非就是以上的两点，把以上两点跟理解了
也就基本上掌握了Spring.

 

 

====================================================================================================

 

 

 

 

springMVC工作原理
标签： spring
2013-11-25 11:19 66121人阅读 评论(13) 收藏 举报
分类：
spring（3）

目录(?)[+]
SpringMVC框架介绍

1) Spring MVC属于SpringFrameWork的后续产品，已经融合在Spring Web Flow里面。

Spring 框架提供了构建 Web 应用程序的全功能 MVC 模块。使用 Spring 可插入的 MVC 架构，可以选择是使用内置的 Spring Web 框架还是 Struts 这样的 Web 框架。通过策略接口，Spring 框架是高度可配置的，而且包含多种视图技术，例如 JavaServer Pages（JSP）技术、Velocity、Tiles、iText 和 POI。Spring MVC 框架并不知道使用的视图，所以不会强迫您只使用 JSP 技术。

Spring MVC 分离了控制器、模型对象、分派器以及处理程序对象的角色，这种分离让它们更容易进行定制。

2) Spring的MVC框架主要由DispatcherServlet、处理器映射、处理器(控制器)、视图解析器、视图组成。
SpringMVC原理图

SpringMVC接口解释

DispatcherServlet接口：

Spring提供的前端控制器，所有的请求都有经过它来统一分发。在DispatcherServlet将请求分发给Spring Controller之前，需要借助于Spring提供的HandlerMapping定位到具体的Controller。

HandlerMapping接口：

能够完成客户请求到Controller映射。

Controller接口：

需要为并发用户处理上述请求，因此实现Controller接口时，必须保证线程安全并且可重用。

Controller将处理用户请求，这和Struts Action扮演的角色是一致的。一旦Controller处理完用户请求，则返回ModelAndView对象给DispatcherServlet前端控制器，ModelAndView中包含了模型（Model）和视图（View）。

从宏观角度考虑，DispatcherServlet是整个Web应用的控制器；从微观考虑，Controller是单个Http请求处理过程中的控制器，而ModelAndView是Http请求过程中返回的模型（Model）和视图（View）。

ViewResolver接口：

Spring提供的视图解析器（ViewResolver）在Web应用中查找View对象，从而将相应结果渲染给客户。
SpringMVC运行原理

1. 客户端请求提交到DispatcherServlet

2. 由DispatcherServlet控制器查询一个或多个HandlerMapping，找到处理请求的Controller

3. DispatcherServlet将请求提交到Controller

4. Controller调用业务逻辑处理后，返回ModelAndView

5. DispatcherServlet查询一个或多个ViewResoler视图解析器，找到ModelAndView指定的视图

6. 视图负责将结果显示到客户端

DispatcherServlet是整个Spring MVC的核心。它负责接收HTTP请求组织协调Spring MVC的各个组成部分。其主要工作有以下三项：

1. 截获符合特定格式的URL请求。
2. 初始化DispatcherServlet上下文对应的WebApplicationContext，并将其与业务层、持久化层的WebApplicationContext建立关联。
3. 初始化Spring MVC的各个组成组件，并装配到DispatcherServlet中。

 

 

 

 

===================================================================

Mybatis

 

什么是Mybatis

 

MyBatis 本是apache的一个开源项目iBatis, 2010年这个项目由apache software foundation 迁移到了google code，并且改名为MyBatis 。iBATIS一词来源于“internet”和“abatis”的组合，是一个基于Java的持久层框架。iBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAO）。

MyBatis参考资料官网：https://mybatis.github.io/mybatis-3/zh/index.html

官网对Mybatis的介绍更加具有权威性：

[java] view plain copy
print?

MyBatis 是支持定制化 SQL、存储过程以及高级映射的优秀的持久层框架。MyBatis 避免了几乎所有的 JDBC 代码和手工设置参数以及抽取结果集。MyBatis 使用简单的 XML 或注解来配置和映射基本体，将接口和 Java 的 POJOs(Plain Old Java Objects,普通的 Java对象)映射成数据库中的记录。

MyBatis是iBatis的升级版，用法有很多的相似之处，但是MyBatis进行了重要的改进。例如：

 

1、Mybatis实现了接口绑定，使用更加方便。

 

在ibatis2.x中我们需要在DAO的实现类中指定具体对应哪个xml映射文件， 而Mybatis实现了DAO接口与xml映射文件的绑定，自动为我们生成接口的具体实现，使用起来变得更加省事和方便。

 

2、对象关系映射的改进，效率更高

 

3、MyBatis采用功能强大的基于OGNL的表达式来消除其他元素。

 

对于IBatis与MyBatis的区别就不再多说了，感兴趣的朋友可以研究一下。

MyBatis的框架架构

看到Mybatis的框架图，可以清晰的看到Mybatis的整体核心对象，我更喜欢用自己的图来表达Mybatis的整个的执行流程。如下图所示：

 

原理详解：

MyBatis应用程序根据XML配置文件创建SqlSessionFactory，SqlSessionFactory在根据配置，配置来源于两个地方，一处是配置文件，一处是Java代码的注解，获取一个SqlSession。SqlSession包含了执行sql所需要的所有方法，可以通过SqlSession实例直接运行映射的sql语句，完成对数据的增删改查和事务提交等，用完之后关闭SqlSession。

MyBatis的优缺点

优点：

1、简单易学

mybatis本身就很小且简单。没有任何第三方依赖，最简单安装只要两个jar文件+配置几个sql映射文件易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现。

 

2、灵活

mybatis不会对应用程序或者数据库的现有设计强加任何影响。 sql写在xml里，便于统一管理和优化。通过sql基本上可以实现我们不使用数据访问框架可以实现的所有功能，或许更多。

 

3、解除sql与程序代码的耦合

通过提供DAL层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测试。sql和代码的分离，提高了可维护性。

 

4、提供映射标签，支持对象与数据库的orm字段关系映射

5、提供对象关系映射标签，支持对象关系组建维护

6、提供xml标签，支持编写动态sql。

缺点：

 

1、编写SQL语句时工作量很大，尤其是字段多、关联表多时，更是如此。

2、SQL语句依赖于数据库，导致数据库移植性差，不能更换数据库。

 

3、框架还是比较简陋，功能尚有缺失，虽然简化了数据绑定代码，但是整个底层数据库查询实际还是要自己写的，工作量也比较大，而且不太容易适应快速数据库修改。

 

4、二级缓存机制不佳

总结

 

mybatis的优点同样是mybatis的缺点，正因为mybatis使用简单，数据的可靠性、完整性的瓶颈便更多依赖于程序员对sql的使用水平上了。sql写在xml里，虽然方便了修改、优化和统一浏览，但可读性很低，调试也非常困难，也非常受限。

mybatis没有hibernate那么强大，但是mybatis最大的优点就是简单小巧易于上手，方便浏览修改sql语句。

 

 

==========================================================

Hibernate

关于hibernate框架的简介
2009-06-02 17:18 IT 百度空间 字号：T | T
一键收藏，随时查看，分享好友！

关于hibernate框架的简介，包括应用程序的分层体系结构和持久化层等。

AD：51CTO 网+ 第十二期沙龙：大话数据之美_如何用数据驱动用户体验

1 应用程序的分层体系结构

随着计算机应用软件的发展，应用程序逐渐由单层体系结构发展为多层体系结构。其中，三层结构是目前典型的一种应用软件结构，如图1左。

表述层：提供与用户交互的界面，如GUI（图形用户界面），web页面等；

业务逻辑层：负责各种业务逻辑，直接访问数据库，提供对业务数据的保存、更新、删除和查询操作；

数据库层：负责存放管理应用的持久性业务数据

三层结构的特点是：所有下层向上层提供调用的接口，具体实现细节对上层透明。层与层之间存在自上而下的依赖关系，即上层会访问下层的API，但下层不依赖于上层。

2 持久化层（如图1右）

（1）什么叫持久化？

在图1右中，分离出的持久化层封装了数据访问细节，为业务逻辑层提供了面向对象的API。

持久（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的数据存储在关系型的数据库中，当然也可以存储在磁盘文件中、XML数据文件中等等。

（2）什么叫持久层？

持久层（Persistence Layer），即专注于实现数据持久化应用领域的某个特定系统的一个逻辑层面，将数据使用者和数据实体相关联。

（3）为什么要持久化？增加持久层的作用是什么？

数据库的读写是一个很耗费时间和资源的操作，当大量用户同时直接访问数据库的时候，效率将非常低，如果将数据持久化就不需要每次从数据库读取数据，直接在内存中对数据进行操作，这样就节约了数据库资源，而且加快了系统的反映速度。

增加持久化层提高了开发的效率，使软件的体系结构更加清晰，在代码编写和系统维护方面变得更容易。特别是在大型的应用里边，会更有利。同时，持久化层作为单独的一层，人们可以为这一层独立的开发一个软件包，让其实现将各种应用数据的持久化，并为上层提供服务。从而使得各个企业里做应用开发的开发人员，不必再来做数据持久化的底层实现工作，而是可以直接调用持久化层提供的API。

（4）目前在持久化层领域，实现模式有以下几种：

A 业务逻辑和数据访问耦合

B 主动域对象模式

C ORM模式

D JDO模式

E CMP模式

3 ORM介绍

ORM（Object Relational Mapping），即对象关系映射。

指以O/R原理设计的持久化框架（Framework），包括 O/R机制、SQL自生成、事务处理和Cache管理等。

ORM的实现思想就是将关系数据库中表的数据映射成为对象，以对象的形式展现，这样开发人员就可以把对数据库的操作转化为对这些对象的操作。因此它的目的是为了方便开发人员以面向对象的思想来实现对数据库的操作。

常用的ORM中间件有：

Apache OJB （http://db.apache.org/ojb/）

Cayenne （http://objectstyle.org/cayenne/）

Jaxor （http://jaxor.sourceforge.net）

Hibernate （http://www.hibernate.org）

iBatis （http://www.ibatis.com）

jRelationalFramework （http://ijf.sourceforge.net）

mirage （http://itor.cq2.org/en/oss/mirage/toon）

SMYLE （http://www.drjava.de/smyle）

TopLink （http://otn.oracle.com/products/ias/toplink/index.html）

其中 Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位，甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准。

二 Hibernate定义

Hibernate是一种Java语言下的对象关系映射解决方案。 它是一种自由、开源的软件。它用来把对象模型表示的对象映射到基于SQL 的关系模型结构中去，为面向对象的领域模型到传统的关系型数据库的映射，提供了一个使用方便的框架。

三 Hibernate的作用

Hibernate 不仅管理Java 类到数据库表的映射（包括从Java数据类型到SQL数据类型的映射），还提供数据查询和获取数据的方法，可以大幅度减少开发时人工使用SQL 和JDBC 处理数据的时间。

它的设计目标是将软件开发人员从大量相同的数据持久层相关编程工作中解放出来。无论是从设计草案还是从一个遗留数据库开始，开发人员都可以采用Hibernate。

四 Hibernate的应用

Hibernate对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合，它既可以在Java的客户端程序使用，也可以在Servlet/JSP的Web应用中使用。最具革命意义的是，Hibernate可以在应用EJB（Enterprise JavaBeans是Java应用于企业计算的框架）的J2EE架构中取代CMP，完成数据持久化的重任。

五 Hibernate API简介

1 Hibernate API中的接口可以分为以下几类：

（1） 提供访问数据库的操作的接口，包括session、Transaction、Query接口；

（2） 用于配置Hibernate的接口，Configuration；

（3） 间接接口，使应用程序接受Hibernate内部发生的事件，并作出相关的回应，包括：Interceptor、Lifecycle、Validatable；

（4） 用于扩展Hibernate功能的接口，如UserType、CompositeUserType、IdentifierGenerator接口。

Hibernate内部还封装了JDBC、JTA（Java Transaction API）和JNDI（Java Naming And Directory Interface）。其中，JDBC提供底层的数据访问操作，只要用户提供了相应的JDBC驱动程序，Hibernate可以访问任何一个数据库系统。JTA和JNDI使Hibernate能够和J2EE应用服务器集成。

2 Hibernate的核心接口框图

六 Hibernate的优缺点

（1）优点：

a.Hibernate 使用 Java 反射机制 而不是字节码增强程序来实现透明性。
b.Hibernate 的性能非常好，因为它是个轻量级框架。映射的灵活性很出色。
c. 它支持各种关系数据库，从一对一到多对多的各种复杂关系。

（2）缺点：

Hibernate限制您所使用的对象模型。例如，一个持久性类不能映射到多个表。

 

 

 

 

 

======================

 

三大框架优缺点
=============================================

MVC

即

Model-View-Controller

的缩写，是一种常用的设计模式。

MVC

减

 

弱了业务逻辑接口和数据接口之间的耦合，以及让视图层更富于变化。

MVC

的

 

工作原理

,

如下图

1

所示：

 

Struts

是

MVC

的一种实现，它将

Servlet

和

JSP

标记（属于

J2EE

规范）用作

 

实现的一部分。

Struts

继承了

MVC

的各项特性，并根据

J2EE

的特点，做了相应

 

的变化与扩展。

Struts

的工作原理，

 

视图：主要由

JSP

生成页面完成视图，

Struts

提供丰富的

JSP

标签库：

Html

，

 

Bean

，

Logic

，

Template

等，这有利于分开表现逻辑和程序逻辑。

 

控制：在

Struts

中，承担

MVC

中

Controller

角色的是一个

Servlet

，叫

 

ActionServlet

。

ActionServlet

是一个通用的控制组件。这个控制组件提供了处理

 

所有发送到

Struts

的

HTTP

请求的入口点。它截取和分发这些请求到相应的动作

 

类（这些动作类都是

Action

类的子类）

。另外控制组件也负责用相应的请求参数

 

填充

ActionFrom

（通常称之为

FromBean

）

,

并传给动作类（通常称之为

 

ActionBean

）

。动作类实现核心商业逻辑，它可以访问

javabean

或调用

EJB

。最

 

后动作类把控制权传给后续的

JSP

文件，后者生成视图。所有这些控制逻辑利

 

用

Struts-config.xml

文件来配置。

 

模型：模型以一个或多个

javabean

的形式存在。这些

bean

分为三类：

Action

Form

、

Action

、

JavaBeanorEJB

。

ActionForm

通常称之为

FormBean

，封装了来

 

自于

Client

的用户请求信息，如表单信息。

Action

通常称之为

ActionBean

，获取

 

从

ActionSevlet

传来的

FormBean

，取出

FormBean

中的相关信息，并做出相关的

 

处理，一般是调用

JavaBean

或

EJB

等。

 

流程：在

Struts

中，用户的请求一般以

*.do

作为请求服务名，所有的

*.do

请

 

求均被指向

ActionSevlet

，

ActionSevlet

根据

Struts-config.xml

中的配置信息，将

 

用户请求封装成一个指定名称的

FormBean

，并将此

FormBean

传至指定名称的

 

ActionBean

，由

ActionBean

完成相应的业务操作，如文件操作，数据库操作等。

 

每一个

*.do

均有对应的

FormBean

名称和

ActionBean

名称，

这些在

Struts-config.xml

中配置。

 

核心：

Struts

的核心是

ActionSevlet

，

ActionSevlet

的核心是

Struts-config.xml

。

 

Struts

优缺点

 

优点：

 

1.

开源软件，能更深入的了解其内部实现机制。

 

2.Taglib

标记库，灵活动用，能大大提高开发效率。

 

3.

页面导航使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统

 

各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者

 

接手这个项目时，这种优势体现得更加明显。

 

4.

提供

Exception

处理机制

.

5.

数据库链接池管理

 

6.Struts

的

Action

必需是

thread

－

safe

方式，它仅仅允许一个实例去处理所

 

有的请求。所以

action

用到的所有的资源都必需统一同步，这个就引起了线程安

 

全的问题。

 

缺点：

 

Taglib

是

Struts

的一大优势，但对于初学者而言，却需要一个持续学习的过程，

 

甚至还会打乱你网页编写的习惯，但是，当你习惯了它时，你会觉得它真的很棒。

 

Struts

将

MVC

的

Controller

一分为三，在获得结构更加清晰的同时，也增加了系

 

统的复杂度。

 

ActionForms

使用不便、无法进行单元测试（

StrutsTestCase

只能用于集成）

 

Spring

的原理和优点

 

Spring

真正的精华是它的

Ioc

模式实现的

BeanFactory

和

AOP

，它自己在这

 

个基础上延伸的功能有些画蛇添足。

 

Ioc

模式是什么

 

可伸缩性和重

/

轻量，谁是实用系统的架构主选？

 

Spring

它是一个开源的项目，而且目前非常活跃；它基于

IoC

（

InversionofControl

，反

 

向控制）和

AOP

的构架多层

j2ee

系统的框架，但它不强迫你必须在每一层中

 

必须使用

Spring

，因为它模块化的很好，允许你根据自己的需要选择使用它的某

 

一个模块；它实现了很优雅的

MVC

，对不同的数据访问技术提供了统一的接口，

 

采用

IoC

使得可以很容易的实现

bean

的装配，提供了简洁的

AOP

并据此实现

 

TranscationManagment

，等等

 

优点

 

a.Spring

能有效地组织你的中间层对象，不管你是否选择使用了

EJB

。如果你仅

 

仅使用了

Struts

或其他为

J2EE

的

API

特制的

framework

，

Spring

致力于解决剩

 

下的问题。

 

b.Spring

能消除在许多工程中常见的对

Singleton

的过多使用。根据我的经验，

 

这是一个很大的问题，它降低了系统的可测试性和面向对象的程度。

 

c.

通过一种在不同应用程序和项目间一致的方法来处理配置文件，

Spring

能消

 

除各种各样自定义格式的属性文件的需要。曾经对某个类要寻找的是哪个魔法般

 

的属性项或系统属性感到不解，为此不得不去读

Javadoc

甚至源编码？有了

 

Spring

，你仅仅需要看看类的

JavaBean

属性。

InversionofControl

的使用（在下

 

面讨论）帮助完成了这种简化。

 

d.?

通过把对接口编程而不是对类编程的代价几乎减少到没有，

Spring

能够促进

 

养成好的编程习惯。

 

e.Spring

被设计为让使用它创建的应用尽可能少的依赖于他的

APIs

。在

Spring

应用中的大多数业务对象没有依赖于

Spring

。

 

f.

使用

Spring

构建的应用程序易于单元测试。

 

g.Spring

能使

EJB

的使用成为一个实现选择

,

而不是应用架构的必然选择。你能

 

选择用

POJOs

或

localEJBs

来实现业务接口，却不会影响调用代码。

 

h.Spring

帮助你解决许多问题而无需使用

EJB

。

Spring

能提供一种

EJB

的替换物，

 

它们适用于许多

web

应用。例如，

Spring

能使用

AOP

提供声明性事务管理而不

 

通过

EJB

容器，如果你仅仅需要与单个数据库打交道，甚至不需要一个

JTA

实

 

现。

 

i. Spring

为数据存取提供了一个一致的框架

,

不论是使用的是

JDBC

还是

O/R

mapping

产品（如

Hibernate

）

。

 

Spring

确实使你能通过最简单可行的解决办法来解决你的问题。而这是有有很大

 

价值的。

 

缺点：

 

使用人数不多、

jsp

中要写很多代码、控制器过于灵活，缺少一个公用控

 

制器

 

Hibernate

的原理和优点。

 

Hibernate

使用了

J2EE

架构中的如下技术：

JDBC

、

JTA

、

JNDI

。其中

JDBC

是一个支持关系数据库操作的一个基础层；它与

JNDI

和

JTA

一起结合，使得

 

Hibernate

可以方便地集成到

J2EE

应用服务器中去。

 

在这里，我们不会详

 

细地去讨论

HibernateAPI

接口中的所有方法，我们只简要讲一下每个主要接口

 

的功能，如果你想了解得更多的话，你可以在

Hibernate

的源码包中的

 

net.sf.hibernate

子包中去查看这些接口的源代码。下面我们依次讲一下所有的主

 

要接口：

 

核心接口

 

以下

5

个核心接口几乎在任何实际开发中都会用

 

到。通过这些接口，你不仅可以存储和获得持久对象，并且能够进行事务控制。

 

Session

接口

 

Session

接口对于

Hibernate

开发人员来说是一个最重要的

 

接口。然而在

Hibernate

中，实例化的

Session

是一个轻量级的类，创建和销毁它

 

都不会占用很多资源。这在实际项目中确实很重要，因为在客户程序中，可能会

 

不断地创建以及销毁

Session

对象，如果

Session

的开销太大，会给系统带来不

 

良影响。

 

SessionFactory

接口

 

这里用到了一个设计模式

――

工厂模式，用户程序

 

从工厂类

SessionFactory

中取得

Session

的实例。

 

令你感到奇怪的是

 

SessionFactory

并不是轻量级的！实际上它的设计者的意图是让它能在整个应用

 

中共享。典型地来说，一个项目通常只需要一个

SessionFactory

就够了，但是当

 

你的项目要操作多个数据库时，那你必须为每个数据库指定一个

SessionFactory

。

 

SessionFactory

在

Hibernate

中实际起到了一个缓冲区的作用，它缓冲了

Hibernate

自动生成的

SQL

语句和一些其它的映射数据，还缓冲了一些将来有可能重复利

 

用的数据。

 

Configuration

接口

 

Configuration

接口的作用是对

Hibernate

进行配置，

 

以及对它进行启动。在

Hibernate

的启动过程中，

Configuration

类的实例首先定

 

位映射文档的位置，读取这些配置，然后创建一个

SessionFactory

对象。

 

Query

和

Criteria

接口

Query

接口让你方便地对数据库及持久对象进行查

 

询，它可以有两种表达方式：

HQL

语言或本地数据库的

SQL

语句。

Query

经常

 

被用来绑定查询参数、限制查询记录数量，并最终执行查询操作。

 

Criteria

接口与

Query

接口非常类似，它允许你创建并执行面向对象的标准化查询。值

 

得注意的是

Query

接口也是轻量级的，它不能在

Session

之外使用。

 

Callback

接口当一些有用的事件发生时

――

例如持久对象的载入、存储、

 

删除时，

Callback

接口会通知

Hibernate

去接收一个通知消息。一般而言，

Callback

接口在用户程序中并不是必须的，但你要在你的项目中创建审计日志时，你可能

会用到它。以下是它的策略接口：

主键的生成

(IdentifierGenerator接口)

本地

SQL

语言支持

(Dialect抽象类)

缓冲机制

(Cache和CacheProvider接口)

JDBC

连接管理

(ConnectionProvider接口)

事务管理

(TransactionFactory,Transaction,

和TransactionManagerLookup接口)

ORM策略

(ClassPersister接口）

属性访问策略

(PropertyAccessor接口)

代理对象的创建(ProxyFactory)

接口

Hibernate