How to avoid loading a LINQ to SQL object twice when editting it on a website.

Question

Hi guys

I know you are all tired of this Linq-to-Sql questions, but I'm barely starting to use it (never used an ORM before) and I've already find some "ugly" things. I'm pretty used to ASP.NET Webforms old school developing, but I want to leave that behind and learn the new stuff (I've just started to read a ASP.NET MVC book and a .NET 3.5/4.0 one).

So here's is one thing I didn't like and I couldn't find a good alternative to it.

In most examples of editing a LINQ object I've seen the object is loaded (hitting the db) at first to fill the current values on the form page. Then, the user modify some fields and when the "Save" button is clicked, the object is loaded for second time and then updated.

Here's a simplified example of ScottGu NerdDinner site.

//
// GET: /Dinners/Edit/5

[Authorize]
public ActionResult Edit(int id) {

    Dinner dinner = dinnerRepository.GetDinner(id);

    return View(new DinnerFormViewModel(dinner));
}

//
// POST: /Dinners/Edit/5

[AcceptVerbs(HttpVerbs.Post), Authorize]
public ActionResult Edit(int id, FormCollection collection) {

    Dinner dinner = dinnerRepository.GetDinner(id);

    UpdateModel(dinner);

    dinnerRepository.Save();

    return RedirectToAction("Details", new { id=dinner.DinnerID });
}

As you can see the dinner object is loaded two times for every modification. Unless I'm missing something about LINQ to SQL caching the last queried objects or something like that I don't like getting it twice when it should be retrieved only one time, modified and then comitted back to the database.

So again, am I really missing something? Or is it really hitting the database twice (in the example above it won't harm, but there could be cases that getting an object or set of objects could be heavy stuff).

If so, what alternative do you think is the best to avoid double-loading the object?

Thank you so much, Greetings!

Answer 1

I don't think there is a way to avoid this in linq to sql... You always need the data in before updating it.

In a lot of cases thats ok, because writes are very rare compared to reads. If you find a particular write is becoming a perf problem, you can always fall back to using a stored proc.

Answer 2

You can create an instance of the Dinner entity, fill in the properties and then call Attach(dinner, true) to pass the entity as modified, it will be updated in database.
You also have control over the set of properties checked for concurrency issues.
In case you have set UpdateCheck to Never for all the properties of the entity in the designer you can achieve the situation when no database querying is performed when the entity is updated.

Answer 3

Web applications are disconnected, each request is individual. Each MVC controller method is a single web request and no state is transferred between the requests in the example you show. There is no way of telling if a lot of time has passed between the initial loading of the values and the post submit to edit the values. What if another user deletes the dinner in the time between the initial load and the edit.

State data can be transferred between web requests by using various options like cookies and session. To achieve what you are describing you would need to store the object beyond the scope of a request. This would avoid the second call to "GetDinner". In ASP.NET MVC this is achieved by using the TempData hash. You could store the dinner in that and then retrieve it from that in the post request. This means a copy of the data is stored temporarily in session from one request to the next. After this it is removed from the session.