2

I'm just starting to learn ASP.NET MVC and I'd like to know how I can retain model objects between subsequent requests to controller action methods?

For example say I'm creating a contact list web app. Users can create, update, rename, and delete contacts in their list. However, I also want users to be able to upload a contact list exported from other programs. Yet I don't want to just automatically add all the contacts in the uploaded file I want to give the user a secondary form where they can pick which uploaded contacts should be actualy added to their list.

So first I have a ContactController.Upload() method which shows an upload form. This submits to ContactController.Upload(HttpPostedFileBase file) which reads the file that was posted into a set of Contact model objects. Then I want to display a list of all the names of the contacts in the list and allow the user to select those that should be added to their contact list. This might be a long list that needs to be split up into multiple pages, and I might also want to allow the user to edit the details of the contacts before they are actually added to their contact list.

Where should I save the model objects between when a user uploads a file and when they finally submit the specific contacts they want? I'd rather not immediately load all the uploaded contacts into the back end database, as the user may end up only selecting a handful to actually add. Then the rest would need to be deleted. Also I would have to account for the case when a user uploads a file, but never actually completes the upload.

From what I understand an instance of a controller only lasts for one request. So should I create a static property on my Contact controller that contains all the latest uploaded contact model object collections? And then have some process that periodically checks the age of these collections and clears out any that are older then some specified expiration time?

Eric Anastas
  • 21,675
  • 38
  • 142
  • 236

4 Answers4

2

A static property on the controller is trouble. First off, it won't work in a web farm and second it you'd have to deal with multiple requests from different users. If you really don't want to use your database you could use the ASP.NET Session.

Mike Valenty
  • 8,941
  • 2
  • 30
  • 32
  • Yeah the static property seemed like a bad idea. Should I be using Session or TempData? I'm reading about both but not sure of the difference. – Eric Anastas Apr 17 '11 at 00:16
  • @Eric Anastas - http://stackoverflow.com/questions/1500402/when-to-use-tempdata-vs-session-in-asp-net-mvc – John Farrell Apr 17 '11 at 01:47
1

No, you don't want a static property, as that would be static to all instances of the controller, even for other users.

Instead, you should create a table used to upload the data to. This table would be used as an intermediary between when the user uploads the data, and completes the process. Upon completion, you copy the contacts you want to keep into your permanent table, then delete the temporary data. You can then run a process every so often that purges incomplete data that is older than a specified time limit.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
0

You could also use the HttpContext.Cache, which supports expiration (and sliding expiration) out-of-the box.

Alternatively, and perhaps even better (but more work) you could use cookies and have the user modify the data using javascript in her browser before finally posting it to you.

However, I'd strongly recommend to store the uploaded information in the database instead.

As you pointed out, it might be a lot of data and the user might want to edit it before clicking 'confirm'. What happens if the user's machine (or browser) crashes or she has to leave urgently?

Depending on the way you store the data the data in this scenario will probably be lost. Even if you used the user id as a cache key, a server restart, cache expiration or cache overflow would cause data loss.

The best solution is probably a combination of database and cookie storage where the DB keeps the information in a temporary collection. Every n minutes, or upon pagination, the modified data is sent to the server and updated in the DB.

mnemosyn
  • 45,391
  • 6
  • 76
  • 82
  • I'm not that concerned with loosing the data. If the user uploads a file and their browser crashes it's not the end of the world if they have to upload the file again. What about using TempData or Session? Although then if I use a Session-State mode other then in proc my UploadData model object would need to be serializable correct? If it makes any difference these uploaded files are around 200kb to 1 mb. Of course I could just be over thinking this as this is my very first ASP.NET site. – Eric Anastas Apr 17 '11 at 00:45
  • `TempData` is basically a wrapper around the session that automatically removes the information in the next request AFAIK. The point is not uploading the file again: It's the **edits** that get lost - that might be extremely annoying. Objects don't need to be serializable - after all, they're not being serialized. 1MB isn't too small. I really don't understand why you don't write this to the DB. – mnemosyn Apr 17 '11 at 00:57
  • Well I ended up with a slightly different solution. When the user uploads the file the server just saves the file, and triggers a work item on the thread-pool to actually read the file and load the data into the database. This way this user is not left waiting for their browser to respond while the server reads through their file. – Eric Anastas May 26 '11 at 18:23
0

The problem with storing the data in session or memory is what happens if the user uploads 50k contacts or more. You then have a very large data set in memory to deal with which depending on your platform may effect application performance.

If this is never going to be an issue and the size of the imported contacts list is manageable you can use either the session or cache to store the dataset for further modifications. Just remember to clear it when the user has committed the changes, you don't want a few heavy datasets hanging around in session.

If you store the dataset in session using your application controller then it will be available to all controllers while it is needed.

Jason Yost
  • 4,807
  • 7
  • 42
  • 65