Armin Waibel wrote:
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.
<snip/>
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?
This looks great to me! I think this is the natural progression now that
so much of the old "PB-API" (=new kernel) is being reused from different
layers.
A clean separation of kernel functions from PB API makes, just as you say,
PB API qualify to the same league as ODMG et al. That might be less
confusing for new users, and is certainly cleaner in the code and promotes
the idea or re-using kernel functions from all layers (using PB API from
ODMG might seem a bit "twisted", but using a kernel from ODMG is natural).
It's less code to maintain and avoids that the same problems are being
solved in different ways in the different API:s.
On a similar note: what happened to Brian's Grafolia? Was that not
also a way of keeping object graph "excercises" centralized in code?
(Did not dig deep enought at the time to really know.)
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
