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