Best practice: INSERT new or hog BLANK row on page load and UPDATE

I have been building web apps for a while now and still do not know the answer to this.

I have just built a web app (using webforms) which has a page for inserting a new budget request and a page to edit and manage this budget request.

What is a pain is if I have to make changes to the business logic then I need to edit same / similar code in two places.

What I am thinking of doing is creating one page to handle this with only UPDATE logic and if the URL on page load has no ID parameter then create a blank row in table and use this new ID and then UPDA开发者_如何转开发TE.

Is this bad practice? I obv know I need to clear out old blank rows at some point....

Thanks

Paul

Look into putting your edit form into a user control, so that it can be reused on both the new and edit page (and any associated back-end code into a separate class that can be referenced in both places).

Yes, I would say it is bad practice to only do UPDATEs; I can imagine various scenarios in which this would bite you later. (E.g. what if you want to have a column that can't be null?)

Yes, it it. You will end up with multiple 'blank' rows in the database it the users do not actually finish creating new requests (I can open 'new' page and then close the browser - you will end up with a black row that never will be updated).

You can still have one page for insert/edit and use 'id' query string parameter. For edits it will be the actual id of the item, for inserts it will be missing. On postback you can then decide whether to insert or edit budget request.

You should abstract the code that saves or updates a record from the form, so it doesn't care. A basic design would be an object that represents the entity, and a Save() method would decide whether to insert or update based on the primary key or ID (being zero or not).

When this becomes trickier is if your form includes data not stored in the same table, e.g. if you had an "organization" with one or more "contacts." Ideally, if someone creates a new organization, then adds contacts, then clicks "cancel," all that could happen without the database ever being touched. In practice, that is not always practical, because your "contact" form is also probably bound to the database the same as your "organization" form, and a "contact" will need to refer to an existing "organization" before it can be saved.

What I usually do is "lazy creation." Don't add a blank row when someone creates an organization. If they create a contact, you will be forced to save the parent object to the database first, otherwise you will have no reference for your contacts. If they cancel the main form without saving, then delete it. Of course, your Delete() method will get rid of the children too.

However, you will need to maintain a state in your parent object to indicate it's conceptually still "new" even after it has been saved to the database in order to handle this. You need this for two reasons: first, so your code knows to delete it if a user cancels without saving, and second, so that the record is not available to any other parts of your application. I usually just use a "Status" flag that is either "New" or "Active."

If you must do this, though, be aware that you can end up with orphans. Nothing will stop a user from creating a new "organization," adding a "contact," which creates a new organization record, and then shutting down their web browser. This is pretty much unavoidable unless you maintain all the form data on the client side (or as session data) until they click "save." While doable, it makes coding this kind of form a lot harder.