oracleobject设计___论文.docVIP

根据上文OracleObject定义，也就是说，会有一张Trade表，一张Product表，一张Account表。其中通过Trade_ID的关联实现了数据层级表现 这样做目的是不希望数据库的表设计与OracleObject太过紧密绑定，以免将来有数据库更换的需求或数据迁移的过程中，遇到不可估计的难度。虽然说没有完全用到OracleObject提供优势，可以在列上使用自定义的数据类型，方便存储和查询，但这里使用了一种折中的方案，放弃了一些性能上和编码上的便利，换来了系统今后升级的空间，而且性能的表现也完全在可接受范围内 在V2版本中，所有Datasheet的保存都是在保存过程的基础上完成的，而OracleObject特性中允许用户自定义类型，因此我们运用OracleObject来保存和访问Datasheet。理由很简单，既然定义和使用了OracleObject，就可以在存储过程中充分使用其面向对象的特性，可以轻易的使用其属性和各种方法。举个例子来看，假设我们定义了INSERT_TRADE，即“插入一笔交易”这个类的保存过程，该类的参数是Trade_Object即交易数据，我们用该类的返回参数替代了返回列表。而操纵Trade_Object就和使用Java对象一样。例如需要使用Trade_id，POB_TRADE中的属性Trade_id就可以了，如POB_TRADE.Trade_id。而对于一个有层级结构对象的查修也非常方便，只需要把相应的表做关联，并把关联表中的属性作为参数传入与之对应的OracleObject的构造器内，就可以构建出Oracle对象。但是对于数组形式的属性，却不能像以上的方法设置，如ACCOUNT_LIST。对于数组我们只有重新定义其保存过程一种方法，如PKG_ACCOUNT.GET_ACCOUNT_LIST(POB_LIST_ID)这个类，其返回值是一个数组，我们必须定义一个外部数组变量作为过渡的变量，利用给该变量赋值将数组中的元素移出，将该变量与ACCOUNT_LIST建立连接。接着根据ACCOUNT_LIST的返回值，将外部数组变量里的元素按顺序逐一复制进ACCOUNT_LIST里的对象，最后移除该外部变量，释放空间，就完成了操作 在完成了数据库方面设计和实现后，需要在Java端进行调用。首先需要利用OracleJPublisher生成相应Java类TradeObject，TradeObjectRef等与数据库对象一一对应的类后OracleObject的方式进行调用了。首先定义ParamValuePairList，是传入SQL语句或者存储过程的参数的集合包括SqlInParameter，SqlOutParameter。如果没有OracleObject，SQL或存储过程的维护都会变得非常困难。在引入OracleObject后，存储过程参数就一目了然，TradeObject这个由JPublisher生成出来的Java对象。同时在完成插入操作后，需要通过查询数据表返回最新TradeObject，用来确保数据一致性。所以在ParamValuePairList里定义了SqlOutParameter是TradeObject.class，SqlInParameter则是TradeObject对象，轻易的就把Trade_Object传递给了存储过程。（这里的存储过程INSERT_TRADE_OBJECT就是上文代码中提及的PROCEDUREINSERT_TRADE） 当然为了支持OracleObject，还需要在原生的存储过程调用方法上进行一些改进。当存储过程的返回值是OracleObject时，原生的JDBC方法是不支持的。所以首先判断ParamValuePairList是否定义ORASqlOutParameter，如果存在，说明存储过程返回值是一个OracleObject。这样就需要返回值Class类型，调用其create方法去创建出这个OracleObject对象 以上代码就是在V2版本中使用OracleObject主要流程。其主要作用是取代了Hibernate在V1版本中对于自定义数据存储实现，利用OracleObject面向对象特性，构建出与真实世界业务对象类似结构，类似于JavaPOJO操作，在存储过程中用OracleObject，这样在数据操纵和查询过程中利用Oracle自身优化引擎对存储过程中使用SQL优化，抛弃了由Hibernate生成HSQL，提高效率。根据测试结果，在20000条数据情况下，性能基本可提升一倍。不仅如此，OracleObject后，也就意味系统和Oracle数据库有着紧耦合，并不利于将来有可能的重构，所以在系统中，多增加一个数据转换层。简单说就是业务数据模型还是使用JavaPOJO对象