Ok here's an odd one.  The client has a popup screen that has a grid on it.  Under the grid is a Add/Edit/Delete collapsable control that has three buttons in it labeled 'Ok', 'Cancel', 'Delete'.  At the bottom of the screen are three more buttons labeled 'Save', 'Apply', 'Reset'.

The idea here is that users can drop open the edit control, and fill out the fields to add a row to the grid.  They can also click a row, which would load the contents of that row into the edit area, which can be modified and then update the grid with an ok click or delete the row from the grid with the delete button.  NONE of these actions will actually update the database.  Also, the edit control area generally has more fields than the grid itself as the grid just displays the summary info for the row.

Save will send all of the changes to the database and close the popup.  Apply will send all of the changes to the database but keep the popup as is.  Reset will return the popup to the initial load state.

Here comes the tricky part: They don't want to cache the dataset!

So apparently they expect me to initially bind the datagrid to a dataset, then on subsequent postbacks just create a dataitem and add it to the controls collection of the datagrid for adds.  Find and delete a dataitem for a delete.  Find and modify a dataitem for edit.  Then when the user hits a button that actually wants to hit the database I'm supposed to parse the entire datagrid dataitems and build a dataset to send to the server.

Most of the historical apps around here were windows forms.  It seems to me that they are trying to design a web application using winforms principles.  Can anyone post some thoughts on how you think this monster will perform and whether it's even feasible to attempt writing this wierd code?

I feel like this is really bad design but I am having trouble eloquently explaining this to the folks in charge.