Application development with Microsoft .NET application blocks

Application blocks
Takeaway: The Microsoft Patterns & Practices group offers chunks of reusable code for developers who are working with .NET languages. Here's a look at the eight application blocks and how you can use them in your next application.

By Mike Gunderloy

Most consultants understand instinctively that time is money: The less time it takes you to deliver a tested, working, complete solution, the higher your hourly rate. One of the keys to better productivity is code reuse. If you have previously tested code that fits the current project’s requirements, you can drop it in to the new application and go on to the next task.

But there’s no reason to limit code reuse to code that you’ve written yourself. There is a tremendous amount of code available on the Internet that you can use. Beware of quality control, of course; downloaded code varies widely in quality. If you’re working in one of the core .NET languages, though, there’s a high-quality repository of reusable code available: the Microsoft Patterns and Practices group. Here’s a look at some of the goodies that this group can provide for your .NET projects.

Patterns and practices
During the last decade, Microsoft realized that it wasn’t enough to just ship development products and then let the rest of us figure out what to do with them. Today’s development environments and client requirements are so complex that it can take years to learn how to write excellent applications. And today’s help files, though comprehensive, can be overwhelming. (Just reading about all of the classes and members in the .NET Framework Class Library [FCL] can take months.)

That’s where the Patterns & Practices group comes into play. Available through the Microsoft Patterns & Practices Web site, the patterns and practices are a series of tested and proven recommendations from Microsoft for use in real-world development. You’ll find four types of information on the site:

1. Patterns that address specific architecture, design, and implementation problems (You can think of these as structured solutions that show you how to do things.)
2. Reference architectures that help you plan server deployments, networks, and other parts of your infrastructure
3. Lifecycle practices that address such issues as trouble-free deployment and operational monitoring
4. Reference building blocks and services that provide you with reusable code that you can drop into your own solution


Of particular interest to the .NET developer are the series of application blocks that you’ll find in the last of these categories.

Application blocks
The application blocks are chunks of reusable code (and documentation) to meet common requirements. Eight application blocks are available:

* The Aggregation application block for aggregating and transforming information from multiple sources
* The Asynchronous Invocation application block for agent-based asynchronous processing
* The Caching application block for caching information in distributed applications (Note that for pure ASP.NET applications, you should probably use the ASP.NET cache instead.)
* The Configuration Management application block for securely reading and writing configuration information from a variety of sources
* The Data Access application block to simplify ADO.NET data access
* The Exception Management application block, which provides an extensible framework for handling exceptions
* The Updater application block, which provides a "pull model" for updating desktop applications over a network
* The User Interface Process application block, a model for writing UI and workflow processes as a distinct layer


What’s in an Application Block?
To get a sense of what the application blocks can do for you, I’ll dig into one of them a bit deeper. Downloading the Aggregation application block gives you a single Windows Installer (MSI) file. Run this file to install the application block on your development computer. Here’s what you’ll get:

* Source code (in both C# and VB.NET) for the Aggregation application block itself
* QuickStart samples (in both C# and VB.NET)
* Documentation in the form of an HTML Help file


The first thing to note is that the application block is supplied as source code rather than as a compiled library. This serves two purposes. First, you can browse through the code and use it for learning, whether you’re more comfortable in C# or in VB.NET. The code in the application blocks tends to be well-structured and well-commented; it seems that there is an internal review process at Microsoft that precedes release.

Second, with shipping source (in Visual Studio .NET 2002 projects), Microsoft offers you the most flexibility in using the code. You can upgrade it to VS.NET 2003, incorporate pieces directly into your own solutions, sign the code so you can deploy it to the GAC, or just compile it as-is and use it as a private library.

The rest of the package ensures that you’re not limited to the source code for the application block when you want to learn what it does. For starters, there’s the QuickStart sample code, which is designed to show the application block in a realistic setting.

For example, the sample for the Aggregation application block shows how to use it in conjunction with the Exception Management application block, the Asynchronous application block, and the Caching application block.
Application development with Microsoft .NET application blocks

ASP.NET Cookies Overview

A cookie is a small bit of text that accompanies requests and pages as they go between the Web server and browser. The cookie contains information the Web application can read whenever the user visits the site.
A cookie is a small bit of text that accompanies requests and pages as they go between the Web server and browser. The cookie contains information the Web application can read whenever the user visits the site.

For example, if a user requests a page from your site and your application sends not just a page, but also a cookie containing the date and time, when the user's browser gets the page, the browser also gets the cookie, which it stores in a folder on the user's hard disk.

Later, if user requests a page from your site again, when the user enters the URL the browser looks on the local hard disk for a cookie associated with the URL. If the cookie exists, the browser sends the cookie to your site along with the page request. Your application can then determine the date and time that the user last visited the site. You might use the information to display a message to the user or check an expiration date.

Cookies are associated with a Web site, not with a specific page, so the browser and server will exchange cookie information no matter what page the user requests from your site. As the user visits different sites, each site might send a cookie to the user's browser as well; the browser stores all the cookies separately.

Cookies help Web sites store information about visitors. More generally, cookies are one way of maintaining continuity in a Web application—that is, of performing state management. Except for the brief time when they are actually exchanging information, the browser and Web server are disconnected. Each request a user makes to a Web server is treated independently of any other request. Many times, however, it's useful for the Web server to recognize users when they request a page. For example, the Web server on a shopping site keeps track of individual shoppers so the site can manage shopping carts and other user-specific information. A cookie therefore acts as a kind of calling card, presenting pertinent identification that helps an application know how to proceed.

Cookies are used for many purposes, all relating to helping the Web site remember users. For example, a site conducting a poll might use a cookie simply as a Boolean value to indicate whether a user's browser has already participated in voting so that the user cannot vote twice. A site that asks a user to log on might use a cookie to record that the user already logged on so that the user does not have to keep entering credentials.
Cookie Limitations

Most browsers support cookies of up to 4096 bytes. Because of this small limit, cookies are best used to store small amounts of data, or better yet, an identifier such as a user ID. The user ID can then be used to identify the user and read user information from a database or other data store. (See the section "Cookies and Security" below for information about security implications of storing user information.)

Browsers also impose limitations on how many cookies your site can store on the user's computer. Most browsers allow only 20 cookies per site; if you try to store more, the oldest cookies are discarded. Some browsers also put an absolute limit, usually 300, on the number of cookies they will accept from all sites combined.

A cookie limitation that you might encounter is that users can set their browser to refuse cookies. If you define a P3P privacy policy and place it in the root of your Web site, more browsers will accept cookies from your site. However, you might have to avoid cookies altogether and use a different mechanism to store user-specific information. A common method for storing user information is session state, but session state depends on cookies, as explained later in the section "Cookies and Session State."
Although cookies can be very useful in your application, the application should not depend on being able to store cookies. Do not use cookies to support critical features. If your application must rely on cookies, you can test to see whether the browser will accept cookies. See the "Checking Whether a Browser Accepts Cookies" section later in this topic.
Writing Cookies

The browser is responsible for managing cookies on a user system. Cookies are sent to the browser via the HttpResponse object that exposes a collection called Cookies. You can access the HttpResponse object as the Response property of your Page class. Any cookies that you want to send to the browser must be added to this collection. When creating a cookie, you specify a Name and Value. Each cookie must have a unique name so that it can be identified later when reading it from the browser. Because cookies are stored by name, naming two cookies the same will cause one to be overwritten.

You can also set a cookie's date and time expiration. Expired cookies are deleted by the browser when a user visits the site that wrote the cookies. The expiration of a cookie should be set for as long as your application considers the cookie value to be valid. For a cookie to effectively never expire, you can set the expiration date to be 50 years from now.
If you do not set the cookie's expiration, the cookie is created but it is not stored on the user's hard disk. Instead, the cookie is maintained as part of the user's session information. When the user closes the browser, the cookie is discarded. A non-persistent cookie like this is useful for information that needs to be stored for only a short time or that for security reasons should not be written to disk on the client computer. For example, non-persistent cookies are useful if the user is working on a public computer, where you do not want to write the cookie to disk.

You can add cookies to the Cookies collection in a number of ways. The following example shows two methods to write cookies:
Response.Cookies["userName"].Value = "patrick";
Response.Cookies["userName"].Expires = DateTime.Now.AddDays(1);

HttpCookie aCookie = new HttpCookie("lastVisit");
aCookie.Value = DateTime.Now.ToString();
aCookie.Expires = DateTime.Now.AddDays(1);
Response.Cookies.Add(aCookie);
The example adds two cookies to the Cookies collection, one named userName and the other named lastVisit. For the first cookie, the values of the Cookies collection are set directly. You can add values to the collection this way because Cookies derives from a specialized collection of type NameObjectCollectionBase.

For the second cookie, the code creates an instance of an object of type HttpCookie, sets its properties, and then adds it to the Cookies collection via the Add method. When you instantiate an HttpCookie object, you must pass the cookie name as part of the constructor.

Both examples accomplish the same task, writing a cookie to the browser. In both methods, the expiration value must be of type DateTime. However, the lastVisited value is also a date-time value. Because all cookie values are stored as strings, the date-time value has to be converted to a String .
Cookies with More Than One Value

You can store one value in a cookie, such as user name and last visit. You can also store multiple name-value pairs in a single cookie. The name-value pairs are referred to as subkeys. (Subkeys are laid out much like a query string in a URL.) For example, instead of creating two separate cookies named userName and lastVisit, you can create a single cookie named userInfo that has the subkeys userName and lastVisit.

You might use subkeys for several reasons. First, it is convenient to put related or similar information into a single cookie. In addition, because all the information is in a single cookie, cookie attributes such as expiration apply to all the information. (Conversely, if you want to assign different expiration dates to different types of information, you should store the information in separate cookies.)

A cookie with subkeys also helps you limit the size of cookie files. As noted earlier in the "Cookie Limitations" section, cookies are usually limited to 4096 bytes and you can't store more than 20 cookies per site. By using a single cookie with subkeys, you use fewer of those 20 cookies that your site is allotted. In addition, a single cookie takes up about 50 characters for overhead (expiration information, and so on), plus the length of the value that you store in it, all of which counts toward the 4096-byte limit. If you store five subkeys instead of five separate cookies, you save the overhead of the separate cookies and can save around 200 bytes.

To create a cookie with subkeys, you can use a variation of the syntax for writing a single cookie. The following example shows two ways to write the same cookie, each with two subkeys:
Response.Cookies["userInfo"]["userName"] = "patrick";
Response.Cookies["userInfo"]["lastVisit"] = DateTime.Now.ToString();
Response.Cookies["userInfo"].Expires = DateTime.Now.AddDays(1);

HttpCookie aCookie = new HttpCookie("userInfo");
aCookie.Values["userName"] = "patrick";
aCookie.Values["lastVisit"] = DateTime.Now.ToString();
aCookie.Expires = DateTime.Now.AddDays(1);
Response.Cookies.Add(aCookie);
For more info Click below link



ASP.NET Cookies Overview