When building a visual web part that uses an ASP form for an interface, what is the generally-accepted "best" way to store the data once the user has filled out the form? The only way I can think of is to take all the values in the form and put them into a custom list item, but I feel like there should be a more efficient way to do this because that process could be quite slow depending on the environment. What other options are there?
Add a comment
|
2 Answers
It depends on what you want to do with the data, I'd say. In general, I would recommend the custom list approach, especially if the purpose of the form is to collect data and use it later. Recently, I built a custom 'poll' web part that did just this - I had a PollResponses list that stored the choice the user submitted through an AJAX request, and then I used that PollResponses list to generate a dataset to graph to show results.
I typically don't see any performance issues with this approach - unless you have over 15000 users who are going to use the form, you shouldn't see any performance issues with the list. Saving data to a list item is typically one of the cheaper operations in a SharePoint request's lifetime - if you're seeing long page load times when doing this, you should turn on the Developer Dashboard and try and get more information.
As far as other options go, you could use a custom SQL database to store the data, but it's not going to be that much faster to work with. It will be easier for other applications to use, however. If this is a form that's only used by one user and is used to configure the application, you could store the data in the Property Bag for the web (or list), but that means that subsequent submissions of the form will overwrite the existing data.
-
I for some reason didn't even think of the AJAX route, I was approaching it with server-side objects that can take some time to fetch. I've begun implementing a SQL table as you suggest (which occurred to me after I posted this) which seems to go okay, and I like the idea of being available to other applications, but we'll have to see if I run into difficulty down the line. If so I think AJAX is a great idea.– thanbyAug 18, 2014 at 16:34
There are certain recommended hardware given by Microsoft. Depending on the traffic you get to your SharePoint server you may need to scale your hardware. Writing to a custom list is the general and the safest method considering the set of operations supported by lists.
If the server side object model is slowing you down, you can use the Javascript client side object model(JS CSOM). As you have mentioned, the SharePoint content db should be the one that is slowing down. So better check your SQL performance on that server. Another big thing is with the async calls in JS CSOM, you will not need to render the page again and again from content db.
Everybody is moving to the CSOM, so you better try.
answered Aug 18, 2014 at 16:42
