本科毕业论文---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，只需要调用OracleObjectPOB_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等与数据库对象一一对应的类后，就可以使用JavaJDBC的操纵这些类以OracleObject的方式进行调用了。首先定义ParamValuePairList，是传入SQL语句或者存储过程的参数的集合包括SqlInParameter，SqlOutParameter。如果没有OracleObject，当需要将数据插入到数据表中，特别当表的字段比较多时，SQL语句会变得非常长难以维护并且需要非常仔细的定义每个列顺序和保证每个数据类型是否一致；如果使用存储过程，将会有定义一系列参数，一般而言参数数量将会和表字段数一致。当数据表需要增加新字段或修改原有字段时，SQL或存储过程的维护都会变得非常困难。在引入OracleObject后，存储过程参数就一目了然，当插入数据到Trade表中，只需要传入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，这样在数据