I have been reading this article:
Many ways to communicate with your database using jQuery AJAX and ASP.NET
This article describes many ways to communicate with the database using jQuery and AJAX. Personally I use .ASHX handlers to get the data.
Can any one tell me which way considered the best in terms of being lightweight and performing well no matter how large the database is?
If you're stuck with ASP.NET forms and aren't able to utilise ASP.NET MVC then .ashx handlers will be fine. They don't have all of the overhead of the full ASP.NET forms .aspx page.
As far as performance is concerned, as always, you should only return the data you need and provided your database is tuned and your SQL queries are sensible then life will be good.
One thing I would suggest is instead of returning HTML, consider returning data as JSON. It's more compact and portable. Also JSON objects rehydrate into javascript objects that you can manipulate directly. There are many JSON serialisers available for .NET, I consider Json.NET to be one of the better ones.
Related
I have a site written in Asp.net webforms. It uses ajax heavily.
Most forms on the site are submited with javascript. Javascript validates the input and sends it to /ajax.ashx on the server. The server processes the request and sends back a JSON response. My javascript uses the JSON to create html, which it inserts into the Dom.
I'm making a new version of my website written using asp.net MVC3. I've been looking at tutorials on this subject, and some of them recommend doing ajax in a different way. Rather than sending data and then building + inserting html with javascript, they create html at the server, and use javascript only to insert it into the Dom. For instance, in this tutorial.
Which way should I use? Using the new method will be quicker, but is it better?
That's a subjective question. Both approaches are possible and there is no better way. There are pros and cons of each approach.
Building the HTML on the server is easier and will require you less efforts but consumes more bandwidth compared to the first approach.
If you decide to go the first way you could use some client side templating framework which might help you simplify the generation of DOM elements on the client.
Creating html code directly into the server and injecting it with an ajax call is very fast and simple, the real problem is that in that way your service is bound to be used with that specific application. By sending RAW data you allow any app to use that data in any way, without bounding it to a specific application.
returning json feels more flexible to me; you can change what happens with your json response, like the layout it results in. If you return html you return data mixed with layout. This doesn't feel right to me.
I believe it is better to separate the layout from the actual data. That is why you should pass data between your scripts and not HTML.
If you go about it sending HTML, consider that you would have to build valid HTML and CSS, which might not sound hard at first but then you'll start using CSS that is not loaded in the file calling the ajax, etc.
Always separate content (data) from layout. That's why there is HTML and CSS, to separate layout from data. So why mess things up by mingling HTML between data?
Building the html serverside will probably be faster and not bog down the client which is important. Rendering data into HTML with javascript takes time and not every browser is fast with js (i.e. older versions of IE) so things can slow down if you're doing a lot of this.
Like previous posters said, it's kinda subjective because it depends on how much you're offloading to the client. I'm of the opinion that if you can do things serverside, you should.
If you are going to be using this service to return JSON to other applications/clients, then it's probably a good idea to just leave it as JSON and let the client do what it needs on their side.
I want to develop a relatively simple application that calculates some value based on several inputs. I dont want a backend, all the calculation can be done in the browser.
Im a little new to JavaScript and WebApps and I came across Backbone.js.
I really like the MVC design, however, they mention a backend a lot. My question:
Is a backend server absolutely required?
Is a backend server optional but without one there isn't much point in backbone.
Or will backbone will really help me out?
Backend is not required.
Backbone can fully work without any backend if your application doesn't require one.
That depends on your application. If you want to retrieve value of some inputs and calculate a result then Backbone won't do that for you - it will help you structure your code. If you app is simple and don't need support for models, views and collections or routing, then there is no point in using Backbone. Hard to answer this question.
For example: Classic todo example application doesn't use any backend.
Backbone.js implements fetch(), save(), destroy() etc. methods on models automatically performing appropriate AJAX requests and parsing response. So it has a strong support for backend via REST services, but it is optional.
You can still use models, views, routers and events without any server-side code. Just don't call REST methods (or override them at your wish).
You can use localStorage for persistence (you'd have to implement this yourself or find it on the web, like here) but if you don't even need that then you don't need to use any of the persistence methods in backbone.
Backbone is meant to help you structure a medium-large sized application (js-wise), so it doesn't become unmaintainable jQuery spaghetti. With short applications (js-wise) it's really an overkill unless you are trying to learn how backbone works.
Note with js-wise I mean the client side code, if you had a huge backend but the only js would be something that focuses some form, it would not even count as a short application (js-wise).
You can use backbone.js without a backend. However you obviously won't be able to store or retrieve data. Backbone may still be useful for keeping your code organized, however it really shines when you want to separate presentation logic from logic that manipulates your data, which is a goal of the MVC pattern. Generally your data will be stored on and retrieved from a backend.
If you want to play around with data persistence, try out backlift.com. [disclosure, I work on backlift.com] We've tried to make it easy to get a backbone app up-and-running without having to setup a server or deal with compiling templates.
I ahve been practicing jQuery.ajax() recently. I have started to learn to call .Net web-services qith jQuery.ajax().
Now I am considering if I will use only jQuery.ajax() calls to some service methods on the server; is it still meaningfull to have .Net Web-Services or I should go with .ashx handlers instead?
Thanks!
Two quotes from the ASP.NET forums:
Unless it's an extremely high load situation, you'll find that all
three perform nearly identically. The performance of your code inside
the handler/service is going to be the limiting factor.
For simple AJAX calls that are only intended to be exposed to the
browser, I don't think WCF justifies its added complexity. It's great
for some things, but I have a hard time recommending it for this.
Between ASMX and HttpHandler, I go with ASMX every time. An
HttpHandler is probably negligibly faster, but an ASMX "ScriptService"
makes JSON serialization and deserialization of complex types
transparent, which is immensely useful.
Here's another option:
If you have some methods you want to run (and you like JQuery)... I
suggest looking at this:
http://encosia.com/2008/05/29/using-jquery-to-directly-call-aspnet-ajax-page-methods/
and related articles. Works beautiful. Very efficient as far as
bandwith goes. They also have an article on querying .asmx services.
There is no messing around with the bloated size of ASP.NET's innate
AJAX. Since AJAX out of the box can be very bloated. Plus it's very
easy.
You should also have a look at microsoft's most recent framework for web services: WebAPI
Personally, I recently switched to ServiceStack.NET for my web services, and I find it's a lot easier and elegant (than WebAPI, or WCF).
a WCF service would be the preferred method over ASP.NET soap web services or ashx services .
We will be using custom Silverlight 4.0 controls on our ASP.NET MVC web page to display data from our database and was wondering what the most efficient method was? We will be having returned values of up to 100k records (of 2 properties per record).
We have a test that uses the HTML Bridge from Javascript to Silverlight. First we perform a post request to a controller action in the MVC web app and return JSON. This JSON is then passed to the Silverlight where it is parsed and the UI updated. This seems to be rather slow, with the stored procedure (the select) taking about 3 seconds and the entire update in the browser about 10-15sec.
Having a brief look on the net, it seems that WCF is another option, but not having used it, I wasn't sure of it's capability or suitability.
Does anyone have any experiences or recommendations?
You should definitely consider a change in your approach. This just shouldn't have to be so complicated. WCF is a possible solution. I am sure you are gonna get better performance out of it.
It is designed to transfer data across the wire. Web services in general are thought to be the "right way" to provide data to your silverlight app. WCF services are definitely more configurable.
Another point in favour of web services is that this approach is more straightforward than the one you apply. You don't have to serialize in JSON then to parse in JavaScript objects and then to pass them to Silverlight.
It is really easy to port and continue developing with wcf.
Last but not least your code will be much more readable and maintainable.
It seems that performance is critical in your case so you can take a look here for compraison.
In conclusion my advice is to consider a change in your approach. WCF services looks like possible solution.
Hope this helps.
I've been developing a "Form Builder" in Javascript, and coming up to the part where I'll be sending the spec for the form back to the server to be stored. The builder maintains an internal data structure that represents the fields, label, options (for select/checkbox/radio), mandatory status, and the general sorting order of the fields.
When I want to send this structure back to the server, which format should I communicate it with?
Also, when restoring a server-saved form back into my Javascript builder, should I load in the data in the same format it sent it with, or should I rebuild the fields using the builder's createField() functions?
When making and processing requests with JavaScript, I live and breath JSON. It's easy to build on the client side and there are tons of parsers for the server side, so both ends get to use their native tongue as much as possible.
This seems like a perfect scenario for using JSON as a serialization format for the server. If you study a few examples it is not too difficult to understand.
Best practice on this dictates that if you are not planning to use the stored data for anything other than recreating the form then the best method is to send it back in some sort of native format (As mentioned above) With this then you can just load the data back in and requires the least processing of any method.
I'd implement some sort of custom text serialization and transmit plain text. As you say, you can rebuild the information doing the reversed process.
There's a lot of people who will push JSON. It's a lot lighter weight than XML. Personally, I find XML to be a little more standard though. You'll have trouble finding a server side technology that doesn't support XML. And JavaScript supports it just fine also.
You could also go a completely different route. Since you'll only be sending information back when the form design is complete, you could do it with a form submit, for a bunch of hidden fields. Create your hidden fields using JavaScript and set the values as needed.
This would probably be the best solution if didn't want to deal with JSON/XML at all.