A general question on where to put validation.
I have an ASP.NET form that gets/sets data from/to a DataSet.
Currently, the fields in the form are validated by the form itself (e.g. for invalid length, range, etc.).
Is it a good... or better idea to transfer this validation checks into the DataSet.
The downside is I need to trigger update calls to the DataSet in order to get the column with errors.
In using forms, I can catch the error earlier.
The main reason I'd prefer to do this is I'd be using this Dataset assembly into another project (a WFC service?). And I'd like to re-use the same validation code when possible.
If you found anything similar to what I prefer to do, please give a link. Thanks!
Validations need to happen at page level (i.e, using javascript) and also at database level. Put in in your database APIs (i.e, using stored procedures). Don't rely solely on front-end validation, and don't commit any data without validation.
You can perform additional checks at Business layer level if need be.
Use both ) DataSet validation is more reliable, but ASP.NET Forms Validation works faster, user don't have to wait server response with validation results. But form validation is easy to cheat, you could create Response mannualy and send it to server without any form validation.
Related
We have a very large HTML form (> 100 fields) that updates a SQL Server database with user-entered data. It will take the user a long time to fill out the form, but every piece of information they submit is very valuable to the business process. Even if the user gives up on the form, we want to retain everything they have entered.
We plan to attach an onblur event to each field and use jQuery/AJAX to post each piece of data back to the application server immediately. That part is pretty straightforward. The question we have is when and how to best save this application-level information to the database. Again, our priority is data retention as opposed to performance but we also want to do this as efficiently as possible.
Options as I see it are:
Have the web service immediately post each piece of data to the database server.
Store the information in a custom class on the application server, then periodically call an update method to post new data to the database.
Store the information in view or session state, then run a routine to post this information to the database server.
Something else that we haven't thought of.
Option 1 seems the most obviously failsafe, but also the most resource intensive. Option 2 seems the most elegant, but can we be absolutely certain that the custom class instance can't be destroyed without first running its update method?
Thanks for your help!
IMHO, I'd really cut up the form into sections (if possible). Since this is ASP.Net, if you are using Web Forms then look into using wizards (cut up the form into logical Steps)
You can do same without Form Wizard, but still cut up the process into logical steps, client-side. You can probably do this in pure JavaScript, but it would likely be easier if you used a framework (jQuery, Knockout, etc.) - the concept remains the same, cut up the form entry process into sections (aka 'Steps') - e.g. using display toggles, divs for each "step", etc.
"retain everything even if abandoned later": assumed that the steps are "hierarchical" where the "most critical" inputs are at the beginning. This makes the "steps" approach even more important - this is a "logical group" (of inputs you really want) so if you do the Step approach, then you can save this data (of this "step") to DB in whatever fashion you deem appropriate (e.g. Ajax, or ASP.Net Post/postback).
Hth...
I would package everything up in some xml or dataset (.getxml) and pass the xml to a stored procedure....
How to pass XML from C# to a stored procedure in SQL Server 2008?
And maybe put the call on a background thread.
http://code.msdn.microsoft.com/CSASPNETBackgroundWorker-dda8d7b6
The xml will be faster than calling the values row by row (RBAR).
You can save just the xml, or shred the xml into a relational table(s).
I am very new to writing ASP.NET web apps..but i've been tasked with doing so. I have an extensive set of web services i've written that work with our backend databases. Up until now, i've written solely desktop apps using these web services. this is my first venture into web applications.
So far i've been doing quite well. But i've come to a point where i'm trying to minimize some postback delays.
I'm using a gridview to have users enter some data for a one-to-many relationship. One of the fields they select from a dropdown list. After selecting this list, i was doing a postback to get the corresponding key value and then displaying it but this took to long. Ideally, this should be instantaneous, so i was wondering what the best approach would be - clientside/javascript - to do a lookup on a list of name-value pairs?
From some preliminary web searching, it appears the two most popular approaches would be to use either a hidden field to store the lists, or to store it in a JSON object?
I'm looking for opinions on the best approach, and how specifically to store this list on the client side? From what i understand, using a hidden field could be the easiest.
Opinions?
I don't think you need to store it at all on the client side but rather do an async Ajax call to the server to retrieve the actual value. You should be able to accomplish this easily by putting the GridView and the displayed label controls into an UpdatePanel where the Trigger is defined as your dropdown list.
In order to construct an entity with quite a lot of information, I need to performe a sequence of forms submitting. Every time I return a view from a controller, I need to pass some id's about the not yet established entity. Right now I inject these pieces of info into hidden fields, and when post back to server, continuing to construct the entity.
This scenario continues for a few times.
I'm very not satisfied with this way of passing sensitive information, and was wonder if there're other more appropriate ways of doing it. I use authorization and authentication, but still worried of some scenarios in which one user could hack these id's, before sending it back to server, and by that, modifying the wrong entity.
Also, seems kind of hard work to pass back and forth the same data. I disqualified the use of sessions, because it reveals a different kind of data disruption threat . (in case of using more than one browser at a time).
How should I perform the mentioned operation?
You can use a secure hash of the data in another hidden field to detect tampering with the values.
Here is an example of how to generate a cryptographically secure hash http://www.bytemycode.com/snippets/snippet/379/
You can secure your data using many approaches, I discussed some of it in this post
http://miroprocessordev.blogspot.com/2012/03/save-aspnet-mvc-application-against.html
http://miroprocessordev.blogspot.com/2012/03/safe-aspnet-mvc-application-against.html
use Cross-site request forgery with token to identify that everytime u send an info it contains same token generated at server side and returned from your html
I've been developing classic ASP pages at the job for the past five years and now we are moving to ASP.NET. I'm trying to understand how to get form field values from one page to another and it seems like there is more than one way to do it. In classic ASPI just called request.form collection and got the information. Which way is recommended in .net? Cross Page, Transfer, or HttpRequest?
Gracias.
It actually depends because I don't always use any particular method. Sometime it is easy to expose as property or sometimes just server.tranfer is fine or sometimes as querystring.
If data is sensitive and/or to many itmes I use Session where you can store an class object of custom type as well and not just basic data type.
And in certain cases I store stuff in DB and just pass an id to the record to next page via querystring or session and retrieve everything I want from DB.
Here is reference to different types available.
I am looking for a better approach to do this.
I have around 70 to 80 hidden fields in my page. This hidden fields are initialized at the server side and then used at the client side for validations, calculations, etc,. using java script.
I wanted to know if there is any other alternative approach to using hidden fields in asp.net. I guess, these many hidden fields are increasing the page size and hence affecting the performance of my web page and I want to do away with it.
FYI: I am working on an asp.net web application.
validations, calculations using javascript are better done when taking JSON as base data.
Just assign to a JS variable a JSON generated server-side, then use it in your JS as an object or array.
I was going to suggest that you describe the information as a data structure, serialize it to JSON, include it in a <script> element (assigned to a variable you can access with your validation code).
… but you'd still be getting the data to the client, so the performance issues don't really go away.
You could look at providing it in an external file, so it can be cached, but I don't know enough about how reusable the data is to say if that is feasible.
In the head of your HTML add some javascript initializing variables with the data you need:
<script type="text/javascript">
var option1 = true;
var option2 = 'some text';
...
</script>
You can then access these variables for your javascript validations.
Agree with the JSON and JS data ideas promoted here - you'd be sending down the information needed for your calcs and validation in a lean format, and it wouldn't be posted back.
This provides a direct means to access your data, rather than some jQuery/DOM search to get your hidden field values, boosting the performance of calcs.
If you're talking about performance in terms of download and render time, and if the JSON representation of your client-side data is huge, then your only other option is making AJAX calls to do the calcs and validations server side, so that your large dataset never travels down the wire in either direction. Be wary though about the AJAX roundtrip time to get an answer back to the user.