Re: Persistance Layer wanted!

From: Billy Verreynne <vslabs_at_onwe.co.za>
Date: 5 Sep 2003 08:21:59 -0700
Message-ID: <1a75df45.0309050721.373e83a0@posting.google.com>

"Manfred Pruntsch" <manfred.pruntsch_at_ifcos.com> wrote

> The application (Business Layer) should not care about the techniques behind
> the persistance
> layer at all! This means, when the database design changes in the
> future,only the persistance layer has to be updated.
>
> Example:
> View from persistance layer to database:
> Select xx, yy from table zz, etc
>
> View from Business Layer to Persiswtance Layer:
> saveObject();
> retrieveObject();
> deleteObject();
> And that's all! The business layer doe3s not need to know anything else
> about SQL. These tree commands are enough.

You mean something like this. Note - no Java.. :-)

SQL> create table xobjects
  2 nologging as
  3 select

  4    object_id,
  5    object_type,
  6    object_name
  7  from all_objects

  8 where owner = 'SYS';

Table created.

SQL> alter table xobjects
  2 add constraint pk_xobjects

  3        primary key ( object_id )
  4        using index;

Table altered.

SQL> create or replace type TXObject as Object   2 (

  3    object_id     number,
  4    object_type   varchar2(18), 
  5    object_name   varchar2(30),

  6
  7 constructor function TXObject( id$ number )   8 return self as result,
  9
 10 member procedure Save,
 11 member procedure Dump
 12 );
 13 /

Type created.

SQL> create or replace type body TXObject as   2
  3 constructor function TXObject( id$ number )   4 return self as result is
  5 begin
  6 self.object_id := id$;
  7
  8 select

  9      x.object_type, x.object_name 
 10        into 
 11      self.object_type, self.object_name

 12 from xobjects x
 13 where x.object_id = self.object_id;  14
 15 return;
 16
 17 exception

 18      when NO_DATA_FOUND then
 19         return;

 20 end;
 21
 22
 23 member procedure Save is
 24 begin
 25 insert into xobjects x
 26 ( x.object_id, x.object_type, x.object_name )  27 values
 28 ( self.object_id, self.object_type, self.object_name );  29 end;
 30
 31
 32 member procedure Dump is
 33 begin

 34    dbms_output.put_line('------------------------');
 35    dbms_output.put_line('TXOBJECT dump');
 36    dbms_output.put_line('object_id   =>' || self.object_id );
 37    dbms_output.put_line('object_type =>' || self.object_type );

 38 dbms_output.put_line('object_name ->' || self.object_name );

 39    dbms_output.put_line('------------------------');

 40 end;
 41
 42
 43 end;
 44 /

Type body created.

SQL> set serveroutput on;
SQL> declare
  2 x$ TXObject;
  3 begin
  4 -- call default constructor
  5 x$ := TXObject( -1, 'WIDGETS', 'My Blue Widget' );   6
  7 -- insert into table
  8 x$.Save;
  9
 10 -- commit changes to the database  11 commit;
 12
 13 -- call our constructor (this will read the row from  14 -- the table if it exists)
 15 x$ := TXObject( -1 );
 16
 17 -- dump the object's content
 18 x$.Dump;
 19 end;
 20 /

---

TXOBJECT dump

object_id   =>-1
object_type =>WIDGETS
object_name ->My Blue Widget
------------------------

PL/SQL procedure successfully completed.

This is very simplistic of course.. but illustrates the basics.

From Oracle 8i, the OCI (Oracle Call Interface) supported using objects "natively" from languages like C/Pro*C (Delphi by default supports this too via its BDE driver running on top of OCI). For Visual Basic and others, Oracle OLE driver can be used.

I'm sure if you dig around the Oracle Java documentation, you will find the details on how to seamlessly (I hope ;-) integrate the above with your Java business layer.

--
Billy

Received on Fri Sep 05 2003 - 10:21:59 CDT