At 06:15 AM 2/13/2004, Stefan Holdermans wrote (in part) >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.) [snip]
I can understand the desirability of this programming model, but what does that mean in terms of the actual system behavior? Are you suggesting that the GUI layer should have no way for the user to control when changes made in the GUI are moved into the app's entity classes (which you want to mean that they're magically guaranteed to make it to the database)? What if the data is not valid? The app's entity classes cannot fully validate the data without consulting the database -- if for no other reason than to report that the underlying data has been modified since this app read it. We know that we don't want to try to duplicate all the "business logic" validation (that needs to be done by the database to prevent broken apps from saving bad data) into each app. Does it mean that any change made in the GUI will be saved, whether the user wants that to happen or not? Suppose the user selects an existing Order, monkeys with the OrderItem info displayed in a grid, then realizes he's working on the wrong Order. If requesting another Order commits the changes that were made without consulting the user, that's not desirable behavior. Is it desirable for the user to have a way to say explicitly "throw away these changes" (possibly by some kind of Edit / Undo mechanism) to handle the "oops, wrong order" case, without at least offering an explicit "save these changes" option? When are the user's changes "committed" -- not necessarily all the way to the database, but to non-GUI data-handling code that promises to save the data eventually? IMHO, it's not possible to leave the GUI -- and thus the user -- oblivious of the notion that, eventually, the data will be placed in persistent storage. J. Merrill / Analytical Software Corp =================================== 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
