In my application, I have a number of data edit forms which have parent/child and parent/child/child data relationships. I am getting the data through a middle tier, so am not pointed directly at the underlying databases. In most cases, the lists and records on the forms are aggregates of data from several normalized tables.

I have been struggling with finding an clear, efficient and accurate way to handle tracking all my primary keys in the various add/edit/save/delete/skip situations. I'd love to handle them through a key handling class, but the whole process starts in the form Load, when you don't yet have much access to your form & its objects. As of now, I'm using a pair of set/get methods on the form to update an array of keys, with a little work on handling new keys being done in the business objects.

I'd appreciate thoughts from anyone who's been down this road before. Are there any relevant design patterns you've used? How much of this have you left to the business tier to handle verus the client tier? I want as much of the functionality as possible standardized and pushed up into parent classes so special coding on each individual form is minimized.

TIA,
Isabel