Well, I think we're in agreement on principle but differ slightly in implementation, but in any case we've wandered away from the op's (Mark's) questions. I wonder if he's still reading the thread.
Of course, a single screen is always going to be simpler to code than a tabbed or multi screen interface, but there's no theoretical mandate for either style. The main point in separating the ui from the business and data layers is to afford the end user the ability and right to design the ui. The next situation he addresses is one in which the same and linked data appears & must be refreshed & editable on more than one screen, so in order for changes to be visible, a commit must be issued leaving him without the option of a rollback. As far as I can see this is just a messy, ui issue. If the end users have to have it, then we've got to code it. A temporary single rw cursor would probably work here with the various component tables, buffered or not, updated en mass at some later point. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Roche Sent: Sunday, July 01, 2007 9:18 PM To: [email protected] Subject: Re: Object engineering #2 On 6/30/07, Lew <[EMAIL PROTECTED]> wrote: > Depends on what you're taking. > Ted's right about buffering and rollbacks, but I think you were > referring to a different concept. Namely that the logic governing > which tables to update and when doesn't belong in the user interface, > it belongs in a business layer with actual storage issues governed by > the data layer. I don't feel that this is an object engineering issue > so much as a question of how strictly we layer our code and how much of the > labor saving features .. in this case the ControlSource property... in VFP we're willing to give up to achieve the perfectly tiered and engineered app. > -Lew > Interesting "view" of the situation, excusing the pun. I see the buffered data as an interface between the user interface and the business objects. The UI can mess with the buffered data all it wants, but it is only when the UI passes a message to the business objects and the business objects do whatever validation or processes they might and then invoke the data methods to save the data. The business objects may choose to revert buffered data or ignore changes that don't go to the back end. Then, they pass the names of the cursor they think should be updated to the data layer, which can use all the great VFP data functions like GetNextModified() and GetFldState() to figure out what data needs updating, and then send the SQl to the backend, using SPT or views or CursorAdaptors. How hard is that? Nothing that ten or twelve man-years of effort can't refine ;) -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
