j2ee应用下基于aop的抓取策略实现

《j2ee应用下基于aop的抓取策略实现》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、J2EE应用下基于AOP的抓取策略实现Datafetching使用了O/RMappingI具的典型J2EE应用都会面临这样一个问题：如何通过最精简的SQL杳询获取所需的数据。很多时候这可不是轻而易举的事悄。默认悄况下，O/RMapping工具会按需加载数据，除非你改变了其默认设置。延迟加载行为保证了依赖的数据只有在真正请求时才会彼加载进來，这样就可以避免创建无谓的对彖。冇时我们的业务并不会使用到依赖的那些组件，这吋延迟加载就派上用场了，同吋也无需加载那些用不上的组件了。典型情况卜'，我们的业务很清楚需要哪些数据

2、。但由于使用了延迟加载，在执行大量Select查询时数据库的性能会降低，因为业务所需的数据并不是一下子获得的。这样，对于那些需要支持大量请求的应用来说町能会产生瓶颈（可伸缩性问题）。來看个例子吧，假设某个业务流程想耍得到一个Person及其Address信息。我们将Address组件配置成延迟加载，这样要想得到所需的数据就需要更多的SQL查询，也就是说首先查询Person,然后再查询Address。这增加了数据库Ai应用Z间的通信成本。解决办法就是在一个单独的查询中将Person和Address都得到，因为我们

3、知道这两个组件都是业务流程所需的。如果在DAO/Repository及底层Service开发特定于业务的Fetching-API,对于那些拥有不同数据集的相同领域对彖来说，我们就得编写不同的API进行抓収并组装了。这么做会使Repository及底层Service过于膨胀，最终变成维护的梦魇。延迟抓取的另一•个问题就是在获収到请求的数据询要一直打开数据库连接，否则应用就会抛出一个延迟加载异常。说明：如果在查询屮使用预先抓取來获取二级缓存屮的数据时，我们将无法解决上面提出的问题。对于Hib^wte來说,如果我们使

4、用预先抓収來获取二级缓存中的数据，那么它将从数据幷而不是缓存屮去获取数据，哪怕是二级缓存屮已经存在该数据。这就说明Hibernate也没有解决这个问题，从而表明我们不应该在查询中通过预先抓収来获得二级缓存屮的对象。对于那些可以讣我们调节查询以获取缓存对象的0/RMappingI具來说，如果缓存屮有対象就会从缓存中获収，否则采収预先抓取的方式。这就解决了上血提到的事务/DE连接问题，因为在查询的执行过程中会同时获取缓存中的数据而不是按需读取（也就是延迟加载）。通过F面的示例代码来了解一下延迟加载所面对的问题及解决

5、办法。考虑如下场景：某领域中有3个实体，分另lj是Employee、DepartmentSDependent。这三个实体之间的关系如下：•Employee有0或多个dependents。•Department冇0或多个employees。•Employee属于0或1个department«我们要执行三个操作:1.获収employee的详细信息。2・获取employee及其dependent的详细信息。3・获取employee及其department的详细信息。以上三个操作需要获取并呈现不同的数据。使川延迟加载有

6、如卜弊端:•如果对实休employee所关联的dependent和department这两个实体使用延迟加载，那么在操作2和3中就会生成更多的SQL查询语句。•在多个杳询语句的执行过程屮需要保持数据库连接，否则会抛出一个延迟加载异常,这将导致数据出现问题。但期一方面，使用预先抓取也存在如下弊端：•对employee所对应的dependents和department采取预先抓取会产牛不必要的数据。•无法在特定的场景下对查询进行调优。在Repository/DAO或底层服务屮使用特定于操作的API可以解决上述问题，

7、但却会导致如下问题：•代码膨胀一不管是Service还是Repository/DAO类都无法幸免。•维护的梦魇一不管是Service还是Repository/DAO层，只要有新的操作都需要增加新的APIo•代码重复一有吋底层服务需要在获取的实体上增加某些业务逻辑，与Z类似，还耍在数据返回前检查DAO/Repository层的查询响应以验证数据可用性。为了解决上面这些问题，Repository/DAO层需要根据不同的业务情况执行不同的查询來获取实体。就像Aspect类所定义的那样，我们可以根据特定的操作使用不同的

8、抓取机制来覆盖Repository/DAO类所定义的默认抓取模式。所有的抓取模式类都实现了相同的接口。«Mefe*ce>OEmployeeFetchingStralegyccm»etch^Str«tergy0qMery€mp*oyeeByW()GEmployeeFetchingStrategylmpICCrn1«CiirgStr«tergyfdChingPMJernirplOquery