使用CachedRowSetDataProvider需要解决的问题

 

1、 缓存的问题

CachedRowSetDataProvider是用来封装CachedRowSetXImpl，而CachedRowSetXImpl则是JDBC2.0的CachedRowSet一个实现。通常，在设计的时候，NetBeans会在我们第一次把一个数据表拖到页面的时候会同时产生CachedRowSetDataProvider和CachedRowSetXImpl，前者放在页面（Page）里，后者放在SessionBean1里。把CachedRowSetXImpl放到SessionBean的好处是，可以把数据很方便地缓存到Session里。

我们都知道，把数据缓存到session实现起来比较简单，但弊端也显然而见：

（1）       每个session一个缓存，随着用户量的增加，session的增加，缓存数量也随之增加，非常消耗内存；

（2）       每个session一个缓存，会导致更新缓存的时候数据不能同步，出现的情况往往是，某些用户还能看到已经删除的数据。

目前的解决方法可以是：

（1）       CachedRowSetXImpl还是放到SessionBean里，在页面载入地时候refresh一次，重新从数据库读取数据。但这样的话就失去了原来缓存数据的好处，同时，内存的负担并没有减少；

（2）       把CachedRowSetXImpl还是放到RequestBean里，这样每次访问都会重新读取数据。这样的话就失去了原来缓存数据的好处。

2、 SessionBean管理的问题

我们知道，CachedRowSetXImpl默认是放到SessionBean1的，这样，随着系统规模增大、CachedRowSetXImpl数量的增多，SessionBean1就会变得非常的庞大，维护非常高。

目前解决的方法是把系统分模块，每个模块维护一个SessionBean，这样每个SessionBean就会相对比较容易维护。

3、 系统分层的问题

按照我们惯性的系统分层架构，比较常见的是Action＋Service＋DAO和Action＋Delegate＋EJB。

反观Visual Web，每个功能模块都耦合性都很强，比如，Table组件跟CachedRowSetDataProvider关联密切，CachedRowSetDataProvider跟CachedRowSetXImpl关联密切，这样就会导致系统的分层非常难。

不得不提的是，CachedRowSetXImpl是放在SessionBean里，它的相关SQL语句也是发在SessionBean里，而SessionBean是属于Action层次的，所以我们就会发现这里持久层和Action层紧密结合，不可分割。

对于这些问题暂时没有解决方法。

4、 系统测试的问题

按照我们的习惯，单元测试是十分重要的。我们一般是使用JUnit做单元测试的框架。前面我们已经讲到，系统分层比较困难，这就会导致单元测试的困难。每次做一些测试都要启动Tomcat或者Application，测试调试都十分麻烦。

目前还没有解决方法，但有个猜想：编写一个测试Visual Web的框架。

需要用到的工具有：

（1）       JUnit，这个没有什么好介绍的

（2）       spice-jndikit，这是一个开源的JNDI provider。由于CachedRowSetXImpl需要使用jndi，所以需要一个JNDI provider。

（3）       DBCP，数据源provider（连接池）。

（4）       一个通用的继承TestCase的用于初始化Visual Web测试的类

然后我们就可以根据这些对Visual Web程序进行测试。由于Visual Web是不可分层，所以我们的测试从页面层面上测试。

5、可移植性的问题