Stefan, Yeah, Thomas' post was crappy. I had the same questions as J. Merrill, and I thought through them on the drive to work this morning. I think that the question of how to keep around an edited version of something without saving it is really separate from persistence, unless you need to persist the edited version; the main need for this seems to be mainly in writing client-side sometimes-connected or standalone editor applications. I don't see a problem right now with this approach:
1. Create a copy of the data in the object you wish to edit. This can be another instance of the same class (not auto-persisted), or some similar class whose instances serve as edited instances of other objects. So if you have a Person object, you may create an EditedPerson or PersonChange or PersonUpdate, etc. This object should probably include a version number of the object it was created to represent, unless it's a single-editor situation or the object is write-locked while editing. 2. If the user decides to quit editing, throw the edited copy away, and optionally write-unlock the main object. 3. If the user saves the changes, merge the data with the main object. I disagree with putting lots of functionality into pure data objects, for lots of good reasons, but in this special case I don't see a problem with the main object containing a Merge(EditedObject) method. Wherever the merging logic is, it can optionally check the supplied version number of the requested change and see if some other user has modified the object in the meantime (if the object was not write-locked). If the object WAS changed in the meantime, it can do one of the things normally done in these sorts of situations (often encountered in replication, etc.): promote one of the changes over the other, see if a peaceful merge is possible and allowed between the two changes, throw an exception, etc. You can also see that this approach would let you do the peaceful merge by tracking individual field versions; this is extra overhead, but probably necessary for some situations. If the object was NOT changed, it's totally okay to proceed. The fields of the main object can be changed and the object persisted. All of this is synchronized as appropriate (duh). So what do you think of this approach? I wouldn't mind using an object-relational autopersistence scheme for the main object if it met my needs; I just haven't gotten around to learning how to use one yet. If you did do the edit logic how I describe, though, I think that it would be necessary to postpone the involvement of the autopersistence mechanism until the end of the merge, for obvious performance reasons. Jeff --- Stefan Holdermans <[EMAIL PROTECTED]> wrote: > > 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)? > > Well, it's not as much about not being able to make changes from the GUI as > about not explicitely creating, reading, updating and deleting in/from a > database. My GUI programmer should let tell the application layer "add this > Person object" instead of "send this Person object to the database". I > agree, in practice the difference might be quite subtle. > > It's my experience that layered enterpise applications tend to be biased to > the database. Despite some really good O/R mapping tools (and due to some > poor ones), I see often see designs in which relational data is mapped to an > object model that has a very heavy relational smell to it, i.e. through all > layers I can clearly see the database scheme. For some reason, for a lot of > developers this approach is quite tempting. I think that in an environment > where database-related functionality is hidden as much as possible, bad > designs like these show up less frequently. > > I really have to admit that I haven't spend a lot of time thinking all this > stuff over. So maybe it was a bad idea to bring it into this discussion. And > maybe, the subject should not have been 'Transparent Persistence', but > something like 'Hiding persisitence-related functionality as much as > possible'. But I just wanted to see what kind of ideas you guys have about > these matters. (I did *not* want to invoke a flame-like outburst from > Thomas, anyway. And I've no intension to reply on such a post.) > > The next couple of months, I'll be busy with other stuff than layerd > enterprise app's, so I don't think these thoughts will be worked out in a > detail yet. But maybe I'll bring in some more concrete insights one day. ;) > > 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 =================================== 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
