I have tried to be removed from this list several times - how can I be removed
-----Oprindelig meddelelse----- Fra: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org] P vegne af Rong Chen Sendt: 17. marts 2006 14:46 Til: openehr-technical at openehr.org Emne: Re: persistence layer Mikael Nystr?m wrote: > 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.) > This could be achieved by querying in-memory objects, why it has to be done in the persistence layer? Maybe you can give some example, Mikael. A generic, full-featured query service is tricky enough to do, so why not separate the persistence concern from query related logic. > >>> 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. > Well, I would prefer to see a generic, all-purpose persistence layer, defined by clear interface. Of course, the characteristics will be different depending which implementation is actually used. Applications should be probably built on top of EHR services, which are also generic, all-purposed. So I wouldn't agree that the persistence layer should be very much defined by any particular application. These two, application and persistence, should be rather decoupled, and the services layer will be in between. [application specific logic] [some advanced use: decision support, automated alert etc] [generic service layer: EHR, Demographics, Terminology, Security..., QueryService(?) ] [generic persistence layer] Cheers, Rong > Greetings, > Mikael > > >
