db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: [OJB 1.x] Separation of PB-api from the kernel
Date Fri, 15 Apr 2005 17:22:14 GMT
hi armin,

i agree, we need to keep the kernel as small as possible (do you remeber 
my posts about pb getting bigger and bigger ?) i always considered the 
pb-api as the kernel, but actually i like the idea of pb-api as just 
another api. imo but we should use a proper naming for the kernel then, 
is pb-internal really correct ?

to me the OJB.java looks like a big 'context' object holding all kind of 
configuration settings, but nothing else.

jakob

Armin Waibel schrieb:
> Hi all,
> 
> For 1.x I suggest to completely separate the PB-api from the kernel. So 
> the PB-api will be an API like ODMG, JDO,... a kind of top-level api.
> Further I want to avoid that OJB.java will became a conglomeration of 
> user and internal used methods. This class should be as simple as 
> possible, because it will be the first class of OJB a newbie will use.
> 
> Currently the first separation in PB-api is made by the 
> PersistenceBrokerInternal interface, but I recommend to do a real 
> separation by declaring PBF and PB as the "PB-api" and introducing in 
> start class OJB.java access methods for each api:
> 
> OJB ojb = new OJB();
> Implementation odmg = ojb.getOdmg();
> PersistenceManagerFactory pmf = ojb.getJdo();
> PersistenceBrokerFactory pbf = ojb.getPBF();
> 
> OJB.java itself have access to the kernel PB pool (maybe OJB manage the 
> pool itself) and can be used by all API's. The current PBF class with 
> static methods should be changed to an interface, then the PB-api is 
> represented by the PB and PBF interfaces.
> 
> The top-level api will have kernel access via OJB.java. I suggest to 
> make a clear separation of user-OJB.java methods and methods only used 
> by the top-level api. Don't know what's the best strategy to do that.
> 
> Maybe if we introduce a interface OJBInternal (or something like that) 
> with access method to the kernel api, e.g. getBroker(PCKey key), ...
> Then we can separate the common OJB methods from the methods used by the 
> top-level api's and the OJB.java user-methods are convenience methods to 
> OJBInternal:
> 
> class OJB
> {
>     private OJBInternal internal = new OJBInternalImpl();
> 
>     public PBF getPBF()
>     {
>         return new PBF(this);
>     }
> ...
> 
> // convenience method for user
>     public PC getPC()
>     {
>         internal.getPC();
>     }
> ...
> 
> // access for top-level api and advanced user
>     public getOJBInternal()
>     {
>         return internal;
>     }
> }
> 
> // could be an inner class of OJB, should be pluggable
> // to allow different implementations/extensions
> class OJBInternalImpl implements OJBInternal
> {
>     ...
> }
> 
> //
> interface OJBInternal
> {
>     // PB access for top-level api, e.g. will
>     // be used by PBF of PB-api
>     public PBInternal getBroker(PBKey key);
>     ...
> }
> 
> Then the top-level api using the PBInternal (PBI) instances in the same 
> way as jdbc-connection instances and the PB-api is a thin layer above 
> the OJB kernel.
> The PB-api separation allows to extend the PB-api with additional 
> features or to replace it with a more sophisticated layer with 
> UnitOfWork/dirty detection stuff.
> 
> Any other suggestions or comments?
> 
> regards,
> Armin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message