Interview Tips Interview Tips, Interview Questions and Answers

13Sep/110

Filtering Data in Web Forms Model Binding

To enable filtering, we’ll update our GetProducts() method to take a keyword parameter like below:

public IQueryable<Product> GetProducts([QueryString]string keyword)

{

    IQueryable<Product> query = db.Products;

 

    if (!String.IsNullOrWhiteSpace(keyword))

    {

        query = query.Where(p => p.ProductName.Contains(keyword));

    }

 

    return query;

}

If the keyword is empty or null, then the method returns all of the products in the database.  If a keyword is specified then we further filter the query results to only include those product’s whose names contain the keyword.

Understanding Value Providers

One of the things you might have noticed with the code above is the [QueryString] attribute that we’ve applied to the keyword method argument.  This instructs the Model Binding system to attempt to “bind” a value from the query string to this parameter at runtime, including doing any type conversion required.

These sources of user values are called “Value Providers”, and the parameter attributes used to instruct the Model Binding system which Value Provider to use are called “Value Provider Attributes”. The next version of Web Forms will ship with value providers and corresponding attributes for all the common sources of user input in a Web Forms application, e.g. query string, cookies, form values, controls, viewstate, session and profile. You can also write your own custom value providers.  The value providers you write can be authored to work in both Web Forms and MVC.

By default, the parameter name will be used as the key in the value provider collection, so in this case, a value will be looked for in the query string with the key “keyword”, e.g. ~/Products.aspx?keyword=chef. This can be easily overridden by passing the desired key in as an argument to the parameter attribute. In our example, we might like the user to be able to use the common “q” query string key for specifying the keyword:

public IQueryable<Product> GetProducts([QueryString("q")]string keyword)

2Nov/100

Background of ASP.NET Session State

ASP.NET session state enables you to store and retrieve values for a user as the user navigates ASP.NET pages in a Web application. HTTP is a stateless protocol. This means that a Web server treats each HTTP request for a page as an independent request. The server retains no knowledge of variable values that were used during previous requests. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides a way to persist variable values for the duration of that session. By default, ASP.NET session state is enabled for all ASP.NET applications.

Alternatives to session state include the following:

*

Application state, which stores variables that can be accessed by all users of an ASP.NET application.
*

Profile properties, which persists user values in a data store without expiring them.
*

ASP.NET caching, which stores values in memory that is available to all ASP.NET applications.
*

View state, which persists values in a page.
*

Cookies.
*

The query string and fields on an HTML form that are available from an HTTP request.

17Feb/100

ASP.NET Interview Questions: Query Strings

A query string is information sent to the server appended to the end of a page URL.
Following are the benefits of using query string for state management:-
. No server resources are required. The query string containing in the HTTP requests for a specific URL.
. All browsers support query strings.
Following are limitations of query string:-
. Query string data is directly visible to user thus leading to security problems.-
. Most browsers and client devices impose a 255-character limit on URL length.
Below is a sample "Login" query string passed in URL http://www.jack-fx.com.com/login.asp?login=testing.
This query string data can then be requested later by using Request.QueryString("login").

(I) What is Absolute and Sliding expiration?

Absolute Expiration allows you to specify the duration of the cache, starting from the time the cache is activated. The following example shows that the cache has a cache dependency specified, as well as an expiration time of one minute.

Cache. Insert ("announcement", announcement, depends, _
DateTime.Now.AddMinutes(1), Nothing)

Sliding Expiration specifies that the cache will expire if a request is not made within a specified duration. Sliding expiration policy is useful whenever you have a large number of items that need to be cached, because this policy enables you to keep only the most frequently accessed items in memory. For example, the following code specifies that the cache will have a sliding duration of one minute. If a request is made 59 seconds after the cache is accessed, the validity of the cache would be reset to another minute:

Cache.Insert("announcement", announcement, depends, _
Date Time. Max Value, _
TimeSpan.FromMinutes(1))

2Feb/100

What is the difference between Server.Transfer and Response.Redirect? Why would I choose one over the other?

Some of we developers may confused about these 2 method,

Server.Transfer() : client is shown as it is on the requesting page only, but the all the content is of the requested page. Data can be persist accros the pages using Context.Item collection, which is one of the best way to transfer data from one page to another keeping the page state alive.

Response.Dedirect() :client know the physical loation (page name and query string as well). Context.Items loses the persisitance when nevigate to destination page.

In earlier versions of IIS, if we wanted to send a user to a new Web page, the only option we had was Response.Redirect. While this method does accomplish our goal, it has several important drawbacks. The biggest problem is that this method causes each page to be treated as a separate transaction. Besides making it difficult to maintain your transactional integrity, Response.Redirect introduces some additional headaches. First, it prevents good encapsulation of code. Second, you lose access to all of the properties in the Request object. Sure, there are workarounds, but they’re difficult. Finally, Response.Redirect necessitates a round trip to the client, which, on high-volume sites, causes scalability problems. As you might suspect, Server.Transfer fixes all of these problems. It does this by performing the transfer on the server without requiring a roundtrip to the client.