Generally, we exchange entity classes between the browser and a web service via JSON, e. g. , returns an array of Widget objects from a web service call. But having the ability to exchange entity classes between the browser and server side makes Ajax programming a lot easier. However, sometime the Entity class contains data that is not safe or must be sent to the browser. You should exclude those sensitive properties for security reasons or to avoid sending large amount of data to the browser.
The Widget class contains the State property, which stores large amounts XML data. So, if you store the Flickr response XML in State, it will take up about 25 to 50 KB. The idea is not to prevent sending Entity classes, but instead create a shallow version of Entity classes that are sent to browser. If you send such giant XML data to the browser via a web service call when it isn’t needed, you waste bandwidth and the response takes longer to down load. Unfortunately, there’s no way to exclude a property from JSON serialization. So, the only way to do it is to make another class that contains only the properties that you want to send to the browser as a web service call’s response. For example, you can create a Widget2 class that contains only Row, Column, and Title properties. On the server-side web service code, you convert the Wid get class to Widget2 and return that to the browser. This reduces the response size.
There are also some data types that you should never send to browser via JSON, such as byte arrays, streams, trees, etc. If any of your Entity classes contains such properties, you must make a lightweight copy of that Entity class and exclude such properties. Such light weight classes will not only save download time but also save request time if the browser wants to send such objects to the web service. Moreover, the light weight objects will save JSON serialization and deserialization overhead because they are both entirely reflection-based.
Ajax web sites are all about having as much functionality on one page as possible. But you can’t deliver the entire UI of the whole web site along with all the functionality in one shot. The Start page needs to fetch the UI from the server on demand as the user explores different areas. For example, there’s a Help link on the top-right corner of Dropthings. com. Clicking on that link pops up a gigantic help section.
ASP.NET Related Interview Questions
|VB.NET Interview Questions||C#. NET Interview Questions|
|ASP.NET Interview Questions||ADO.Net Interview Questions|
|Windows Presentation Foundation(WPF) Interview Questions||Windows CE .NET Interview Questions|
|Dot Net Framework Interview Questions||Asp Dot Net Mvc 4 Interview Questions|
|Asp Dot Net Mvc Interview Questions|
Introducing Web Portals And Dropthings.com
Architecting The Web Portal And Widgets
Building The Web Layer Using Asp.net Ajax
Building The Data And Business Layers Using .net 3.5
Building Client-side Widgets
Optimizing Asp.net Ajax
Creating Asynchronous, Transactional, Cache-friendly Web Services
Improving Server-side Performance And Scalability
Improving Client-side Performance
Solving Common Deployment, Hosting, And Production Challenges
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.