Frans, > First of all, let me say that 'transparent > persistence' is a good candidate for buzzword bingo. What > exactly is transparent persistence? Is it the total absence > of any persistence logic whatsoever? Or is it the absence of > a separate broker/adapter object so all persistence behaviour > is inside the object?
I think, for me transparent peristency is about keeping the number of places where peristency-related code appears as small as possible. Calling a Save method from presentation-layer code is a good example: I don't like Save methods hanging around in the GUI. I thinks this means that persitence-related code is to be pulled out of an app's entity classes and pushed into a central service. This service, then, is to be called from as few places as possible. (Just brainstorming here.) > There is no reason for panic though. If you look at > it in the way that entities live in the database, and in > memory you only hold mirrors of these entities, (which comes > down to as much stateless programming as possible) it's more > acceptable you have multiple mirrors somehwere in memory. If > you think in objects and that these have to be saved > somewhere sometime, it's much harder to accept you have > multiple instances with the same values or better: > representing the same entity. Mmmmm ... Okay. But the thing I like from the 'hard way' is that it centralizes the application layer instead of the data layer. Regards, Stefan =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
