views:

35

answers:

1

When I'm developing ASP.NET applications I often create forms that allow users to create, retrieve, or update records in a database. Many times there's a need to be able to add child records to an item I am creating, such as adding a category to a product or some sort of order / order detail relationship. Normally I use some sort of DropDownList to show a list of possible child records, and then a DataGrid to show which children are already a part of the parent. Currently, the only way I know to accomplish this in ASP.NET requires that I first save the parent record to the DB so that I can assign PK/FK relationships so I am able to DataBind the DataGrids that hold the child records.

What I'd like to know is if there is some way I could implement the form so that I could add or remove records from these DataGrids but not actually commit the changes until the user clicks 'Save' to create or update all the required records at once. I'm starting to migrate from using SubSonic to LINQ if that would work better for the DataBinding. It seems pretty difficult with the statelessness of HTTP.

Any thoughts are greatly appreciated,

Mike

+1  A: 

You could use a cached DataSet for this. They're pretty much made to be used as in-memory representations of table-based relational data. I actually really don't recommend this approach for a variety of reasons, but you can cache your DataSet on the server, allow the user to interact with it (adding, editing, deleting and so forth) through postbacks, and then only persist the changes to the real underlying database at the end.

I think a better way of doing this, however, is to make all the changes to the underlying database as the user enters them within a transaction, and then only commit the transaction at the end.

MusiGenesis
If you don't mind me asking, why don't you REALLY recommend your recommendation? Is it due to the performance issues I read about i regards to DataSets?
Mike C
If you don't commit data early and often in a web app, you could lose everything you have done if you let your session expire.
Christian Hayter
@Mike C: Christian's point is a big part of the problem. Also, I don't generally like the idea of caching things in a web app, since it means allocating server resources to something that *may* never be used at all. And a DataSet is usually a pretty large thing to cache.
MusiGenesis
@Mike C: whereas a transaction id is a very small thing to cache, and it allows the user's tentative changes to be stored in the database itself, which is good for storing things.
MusiGenesis
@Mike C: ADO.Net DataSets perform quite well, by the way. I think they're generally faster than ORMs (bring on the flame war!).
MusiGenesis
Haha, I'll spare you the flames you will likely get by siding with ANYTHING Microsoft. One situation that might not work well for committing early and committing often is when there are required fields on a form. This usually means that there is then some sort of order of operations on the form (i.e. you have to make sure that product name is filled out before you can assign it a category). Sometimes that hurts a form's ability to be intuitive.
Mike C
@Mike C: in my experience, most of the DataSet-hating actually comes from the .Net crowd (who only hate Microsoft in the same sense that they hate their wives). People outside of .Net don't really know or care about DataSets.
MusiGenesis
@MusiGenesis,So I suppose there's really not much I can do, and will just have to adjust how I design these data input forms.
Mike C
@Mike C: if you've already designed everything to save changes into the database immediately, then your simplest (and I think best) is to save everything using a Transaction that you store in the user's Session. Your Submit button then just has to Commit that saved Transaction.
MusiGenesis