db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: [OJB 1.x] Separation of PB-api from the kernel
Date Fri, 15 Apr 2005 19:03:39 GMT
Jakob Braeuchi wrote:
> 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 believe we can found such posts 2 years ago ;-)
But I think while refactoring for 1.x we can separate some more components.


> 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.
>

For me the PB-api is a subset view of the OJB-kernel. The kernel is the 
"real O/R mapping layer". PersistenceBrokerInternal (PBI) represents the 
kernel "O/R pipe" and PersistenceBroker is a subset of that functionality.
What will be a proper naming for the OJB-kernel and PBI?
I think 'OJB kernel api' is sufficient, because this term will only be 
used by developer and PBI is a part of the kernel api.

I'm not satisfied with the PBI class naming, but I don't found a more 
characteristical name (OJBBroker, KernelBroker, KernelConnection, 
OJBConnection, ...).

regards,
Armin


> 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
> 
> 
> 

---------------------------------------------------------------------
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