Perhaps it is my lack of experience still with really stretching MVC and Entity Framework but I've run into a problem I can't really figure out.
Up until now my applications have been simple: I show and hide a few divs in a View, and when the user has entered all data they hit submit and I save it to the database using EF. The complication I have now is I have basically have to have a flow where:
Person Registers -> Register Another Person? If Yes -> Person Registers -> And So On...
EDIT* To Clarify: Person comes in to Register a group of people. The first screen is a form where they enter identification info, next is clicked, and then They are asked if they'd like to add someone else, if they click yes they repeat that process. I create a Registration Object each time this happens until they don't want to add anymore, after which they are directed to a "Confirmation" action that shows them their registrations and let's them submit their registrations.
I need to have a way to temporarily hold that data while the user jumps to different actions and ultimately submits it to be saved. I'd prefer not to hold a bunch of models in a Session variable.
Well, in your given example, you shouldn't be holding on to anything. After each person is registered, that data can be saved to the database immediately before redirecting back to the form to allow the user to register another person. At each step, you're dealing with a discrete unit, so there's no reason not to just save it immediately.
In a different scenario, perhaps something like a wizard, where you collect partial info in multiple steps, which culminate to produce one discrete unit, your only real option is to use something like TempData. TempData is still session-based, and uses the Session object under the hood, but it does have the advantage over traditional use of Session that the data is only persisted through the next request, whereas Session data is persisted for the life of the session, which can be anywhere from minutes to weeks based on configuration.
Related
I am trying to convert my asp.net mvc4 app, which had fairly heavy use of SessionState, into a stateless app. I understand that I can store this information in the DB, and intend to do so.
My question, though, is about my particular architecture. My app has a main 'page' consisting of a number of partial view panels, which each have actions in them that can affect the other panels. What i've been doing up to now is storing the entire state of the viewModel (lots of inter-related EF list collections and 'record' objects) in the session, and its been working great. Except when the session just randomly dies.
So, I need to get this data out of the session, and into the DB where I can rebuild the thing at need. My concern is that, if I store the info in the database, every single action done on screen might affect 3-5 different panels, each with their own State updates, thats a minimum of 10 round trips to the DB for every interaction!
What are some strategies I can use to make this idea more scalable?
EXTRA INFO
The view in question here is a sort of POS shopping cart system. There are panels for selecting events, selecting/adding items to the cart, editing cart items, selecting contacts, editing contacts, displaying the cart items, displaying the cart 'subtotals', and finally, a panel with a [checkout] button.
Selecting a new event will change the list of available items. Selecting an item to add to the cart will change the cart item list, subtotals, as well as the checkout panel. Same for editing a cart item.
The main concern is how to recover from a lost session, as I've found the built-in asp.net session code too unreliable. My testers have encountered issues with sessions timing out, and then my app not having any kind of recovery process. When its installed on 1500 sites, each with an average of 10 users, its going to be a plague of lost session issues, and I need to combat that before it becomes a real problem.
I agree that I'm not going stateless...wrong choice of words used in a rush. I'm just trying to move that state into a form that I can rely on past the session failure. My main idea presently is to continue using the session as the local cache for the viewModel data, but to have a fallback operation that can rebuild the viewModel from DB if the session one is lost somehow.
You shouldn't necessarily be using a database to store (what sounds like) data that only needs to be persisted in the short term.
If these changes to the other partials are only relevant in the context of the current "master view," then I would suggest using jQuery AJAX to send off the requests, parse the response JSON and update the other views. Tutorials on jQuery AJAX and ASP.NET MVC are easy to find, if you don't already have the knowledge:
http://www.codeproject.com/Articles/41828/JQuery-AJAX-with-ASP-NET-MVC
This way, you don't need to make a bunch of round trips. If the changes need to be persisted beyond the context of the current view, make ONE round trip to the database to perform the update and then simply update all of the other partials from the in-memory response from the AJAX call.
You don't need to read from secondary storage multiple times when you already have all of the information you need in-memory. Just do the reading and writing once.
I decided to go with a hybrid approach. I'm still using session, but I'm building out a DB 'recovery' option, so that if the session portion is lost, the DB will be able to provide the values needed to rebuild the session seamlessly.
Seems to be working well, so far.
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?
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.
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.
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.
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.
I have a form where the user can choose options from a lot of select boxes. The form is used to register several items from an RSS feed. The user fills in the form, clicks create and is presented with the same form for the next item in the list.
Sometimes, the same options are valid for several items in the list, and I would like to be able to save some of the selections done so the user doesn't have to make the same selection for the next items.
What is the best way of doing this? I've identified four ways of doing it:
Sessions
Just keep the values in the session hash. This will of course work and is very simple, but I have some undefined feeling that it is a bad idea. It will also not work if the user is using the form from different tabs in the browser.
Cookies
Basically the same as keeping them in the session, I think.
Profile
Can't be done in this case I believe, since profiles are shared between several users.
Database
The most complex way I've come up with is to keep the information in the database and use a query parameter to keep track of which information should be used. This is probably overkill, but in some ways the best way to me. I don't like the idea of keeping this kind of state in session or cookies.
Am I missing some way? Or something?
If after filling first form, some data is saved to db (object is created) then you can use this data from db to fill up new form.
If after filling first form, nothing is saved to db, then you can create in memory some objects based on params from previous post and based on this (on just on params) you can prepare new form. But of course data from previous form should be added as hidden fields in second form.
I'd like to ask for a solution. For example we have a page. And I have a link to a another action from this page. I want to have an ability to save the values of entered data on the page.
For instance I go to another page enter data and go back. Like the wizard. But the problem is that we can come to the action from different pages. And it need to save several data types.
Is it understand?
Any suggestions?
I'd like to have common solution....
You could also use TempData to persist data between requests.
In the past for wizards I have used Session to store data as it gets built up along the way.
One thing to not forget is to validate the data you are storing in the session everytime you go to use it. If not a user can exploit the back button to fake certain scenarios. For example:
User uses the wizard and gets to step 3 in the wizard.
They then go to another page that is not part of the wizard.
Then the user enters the wizard again and
only gets to step 2 of the wizard.
User then uses the back button to go all
the way back to the original wizard
that they were on step 3 for.
In this case the data in your session if posted will think it came from the original wizard even though the data in the session is reflecting only up to step 2 from when the user accessed the wizard the second time. Use a unique key each time someone starts a wizard and validate it at each step.
Hope that helps and isn't too confusing (it was a bit to me typing it).
An alternative is to persist the data via the TempData but each time you will need to pull it out and persist it for posting back to the next step. Then rebuild it, add to it and repeat. This can be a lot of work as well but at least you don't have to worry about things happening out of synch.
I'm developing a webapp that allows the editing of records. There is a possibility that two users could be working on the same screen at a time and I want to minimise the damage done, if they both click save.
If User1 requests the page and then makes changes to the Address, Telephone and Contact Details, but before he clicks Save, User2 requests the same page.
User1 then clicks save and the whole model is updated using TryUpdateModel(), if User2 simply appends some detail to the Notes field, when he saves, the TryUpdateModel() method will overwrite the new details User1 saved, with the old details.
I've considered storing the original values for all the model's properties in a hidden form field, and then writing a custom TryUpdateModel to only update the properties that have changed, but this feels a little too like the Viewstate we've all been more than happy to leave behind by moving to MVC.
Is there a pattern for dealing with this problem that I'm not aware of?
How would you handle it?
Update: In answer to the comments below, I'm using Entity Framework.
Anthony
Unless you have any particular requirements for what happens in this case (e.g. lock the record, which of course requires some functionality to undo the lock in the event that the user decides not to make a change) I'd suggest the normal approach is an optimistic lock:
Each update you perform should check that the record hasn't changed in the meantime.
So:
Put an integer "version" property or a guid / rowversion on the record.
Ensure this is contained in a hidden field in the html and is therefore returned with any submit;
When you perform the update, ensure that the (database) record's version/guid/rowversion still matches the value that was in the hidden field [and add 1 to the "version" integer when you do the update if you've decided to go with that manual approach.]
A similar approach is obviously to use a date/time stamp on the record, but don't do that because, to within the accuracy of your system clock, it's flawed.
[I suggest you'll find fuller explanations of the whole approach elsewhere. Certainly if you were to google for information on NHibernate's Version functionality...]
Locking modification of a page while one user is working on it is an option. This is done in some wiki software like dokuwiki. In that case it will usually use some javascript to free the lock after 5-10 minutes of inactivity so others can update it.
Another option might be storing all revisions in a database so when two users submit, both copies are saved and still exist. From there on, all you'd need to do is merge the two.
You usually don't handle this. If two users happen to edit a document at the same time and commit their updates, one of them wins and the other looses.
Resources lockout can be done with stateful desktop applications, but with web applications any lockout scheme you try to implement may only minimize the damage but not prevent it.
Don't try to write an absolutely perfect and secure application. It's already good as it is. Just use it, probably the situation won't come up at all.
If you use LINQ to SQL as your ORM it can handle the issues around changed values using the conflicts collection. However, essentially I'd agree with Mastermind's comment.