Hi all,

Rong Chen wrote:

> Bert Verhees wrote:

>> Dear Mikael, since I initially started the discussion, I explain what 
>> my needs/opinions are.
>> 
>> A good persistence-layer reflects the classes which want to be 
>> persistent.
>
> Do you have any specific need for queries? If you don't need to query
> the internals of the objects (or tree of them), it will be quite simple
> to just serialize the whole object.

I agree with Rong that in simple cases is it enough with serialized objects.
(But I must say that the alternative with applications like "real time data
driven decision support systems" is much more scientifically interesting and
fun. Otherwise we probably not use the full potential of openEHR.)

>> The classes do not need to know what DB-vendor is involved.
>> There will be no db-vendor specific code in the main application, the 
>> db-vendor specific code will be in the persistence layer There is an 
>> abstraction between DB-vendor and classes that want to be persistent.
>> Post-relational-db's, XML-db's, relational DB's of all vendors should 
>> be accessible over the same code-interface.
>
> Agree with all these. Hiding these details behind some interface for
> accessing the persistence layer would work.

Of cause it is possible to hide everything behind a persistence layer
_interface_ and doesn?t talk anything about what we have behind the
interface. But the subject and quite many of the mails had talked about the
persistence layer (and not the interface), then it is necessarily to know
what kind of application it should support.

        Greetings,
        Mikael



Reply via email to