Visual Basic .NET Developer's Guide to ASP .NET, XML and ADO.NET

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (11) from $1.99   
  • New (4) from $16.87   
  • Used (7) from $1.99   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$16.87
Seller since 2007

Feedback rating:

(182)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
Brand New. Remainder mark. Ship daily. Pack carefully. E-mail when shipped. 59C -- $1 OFF IF YOU BUY 2 OR MORE BOOKS. USE CODE TVHQ68XV

Ships from: Denver, CO

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$31.94
Seller since 2008

Feedback rating:

(18050)

Condition: New
Brand New, Perfect Condition, Please allow 4-14 business days for delivery. 100% Money Back Guarantee, Over 1,000,000 customers served.

Ships from: Westminster, MD

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
$31.95
Seller since 2007

Feedback rating:

(23706)

Condition: New
BRAND NEW

Ships from: Avenel, NJ

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
$57.06
Seller since 2014

Feedback rating:

(6)

Condition: New
New

Ships from: Idyllwild, CA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Page 1 of 1
Showing All
Close
Sort by

Overview

This is the book every Internet application developer needs to quickly get up-to-speed on the new .NET and Visual Studio .NET technology used to build Windows applications. The authors provide authoratative information about the Common Language Runtime and .NET Foundation Classes, which form the building blocks for application development in the .NET universe. The construction of Web Services and how they communicate with each other is demystified by the thorough coverage of ASP.NET, XML, and ADO.NET.

Visual Basic® .NET Developer's Guide to ASP.NET, XML, and ADO.NET provides:

  • Unbiased, in-depth commentary on the efficacy of the various technologies that comprise .NET as they pertain to Internet database developers
  • Technical know-how without crushing the reader with pointless detail
  • Implementation details that replace and extend the existing Active Server Pages (ASP), XML, and ActiveX Data Object (ADO) functionality currently supported by Microsoft
  • Practical Visual Basic .NET code examples that illustrate operations used most often by application developers
  • Thorough reference material to the objects available in the Foundation Class libraries

0672321319B04022002

Read More Show Less

Editorial Reviews

From The Critics
Identifies differences between active server pages (ASP) and the new ASP.NET, and explains how to develop internet applications with Visual Studio .NET technology. The authors describe changes in the control model, the event model, and the separation of code from presentation, and introduce the capabilities offered by web services, web forms, HttpHandlers, HttpModules, and the XML data format. The final chapter overviews the common types of database operations performed with ADO.NET. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780672321313
  • Publisher: Addison-Wesley
  • Publication date: 2/27/2002
  • Pages: 592
  • Product dimensions: 7.40 (w) x 9.13 (h) x 1.49 (d)

Meet the Author

Jeffrey P. McManus is a developer specializing in online application development and a popular speaker at conferences such as VBITS, VSLive, and VBConnections. He is a frequent contributor to journals and is the author of four books on database and component technologies and two books on .NET technologies, including Visual Basic® .NET Developer's Guide to ASP.NET, XML, and ADO.NET (Addison-Wesley, 2002).

Chris Kinsman has been responsible for several high-traffic sites based entirely on Microsoft tools, including serving as Vice President of Technology at DevX.com. Chris also spent 10 years consulting with Fortune 500 companies worldwide to solve their needs by utilizing a variety of Microsoft Visual Studio and Back Office technologies. Chris regularly speaks at the VBITS/VSLive, Web Builder, and SQL2TheMax conferences.

0672321319AB01092003

Read More Show Less

Read an Excerpt

Preface

Problems with ASP Today

When Active Server Pages (ASP) was first introduced almost five years ago, it was seen as an answer to the awkward techniques used at that time for creating dynamic content on the Web. At the time, Common Gateway Interface programs or proprietary server plug-ins were the way that most of the Web's dynamic content was created. With the release of ASP 1.0, Microsoft changed all that. ASP 1.0 provided a flexible, robust scripting architecture that enabled developers to rapidly create dynamic Web applications. Developers could write in VBScript or JScript, and Microsoft provided a number of services to make development easy. At the time, it was just what developers needed. As Web development matured, several shortcomings of the platform became evident and persist until today.

Separation of Code and Design

As the Web grew in popularity in the early '90s, developers experienced three distinct waves of development paradigms. In the first wave, Web developers created static HTML documents and linked them. This was the era of the "brochure" Web site and was more about looks than anything else. The second wave brought the concept of dynamic content to the fore. Developers started creating registration forms and various small pieces of functionality and adding them to existing Web sites. The third wave was when the first and second waves came together. Web sites were being designed from the ground up to be interactive; they were treated more like an application and less like a magazine with a subscription card in it. In most instances, this type of interactive page design created a development paradigm that went like so:

  • Designers created page mockups in HTML.
  • Developers added code to the pages.
  • When designers needed to change their design, they copied and pasted the existing code into the new page, butchering it and destroying its functionality.

The severity of this problem typically depended on the size of the site, the smarts of the designers, and the techniques that developers used to guard against this mangling.

With the release of Visual Studio 6 in September of 1998, it was clear that Microsoft recognized this burgeoning problem and attempted to resolve it with a new feature in Visual Basic 6--Web Classes. Web Classes made an attempt to separate the design of a page from the code that interacted with it. It enabled this separation by using an HTML template and providing a facility for doing tag replacement in the template. However, a number of problems occurred with Web Classes. Although a great idea, they suffered from two main issues. First, the Web Classes were implemented entirely in Visual Basic, which required traditional ASP developers to shift their thinking patterns for creating applications. Second, Microsoft had scalability issues related to the threading models of ASP and Visual Basic. Because of the previously stated reasons and many other smaller ones, Web Classes never really gained any traction among developers.

Scripting Language Based

When ASP 1.0 was first released, the fact that all development was done using scripting languages was a big plus. It meant that developers didn't have to go through a painful restart/compile process that they might have been accustomed to with CGI or ISAPI style applications. A grew larger, numbers of users increased, and developers were using ASP for increasingly difficult problems. The fact that all code was interpreted became a potential performance bottleneck. With VBScript, limited support existed for error handling.

Many developers sidestepped this issue by moving code into compiled COM objects. Although this move solved some of the performance problems, it created new ones in deployment and scalability.

State Management

One of the most frustrating aspects that new Web developers faced early was dealing with the stateless nature of Web development. With ASP 1.0, Microsoft introduced the concept of a Session object, which was designed to make associating state with a particular user easy. This addition was arguably one of the most compelling features of ASP 1.0. Scalability and reliability started to become important as developers began creating larger applications. To address this need, developers started deploying their applications to Web farms. Web farms use multiple servers and spread the request for pages across the servers somewhat equally. This makes for a great scalability story... unless the developer is using that cool Session object. This object is specific to a particular machine in a Web farm and will not work if a user gets bounced to another server. Therefore, an application that was deployed to a Web farm could not use the Session object.

Introducing ASP.NET

ASP.NET is Microsoft's answer to the aforementioned problems and many others that were not explicitly stated. It is a fundamental rewrite of ASP that has been in process for more than two years. The ASP team took a close look at the problems facing Web developers and created a brand-new platform in the spirit of traditional ASP to solve those problems. Having used ASP.NET for a considerable amount of time, we can conclusively say they hit a home run with this release.

Platform Architecture

ASP.OLD was an Internet Server Application Programming Interface (ISAPI) filter that was written specifically to interact with Internet Information Server (IIS). It was monolithic in nature and relied very little on external services.

Note:In the IIS 5.0 time frame, ASP did use Microsoft Transaction Server (MTS) as an external service.

ASP.NET is still an ISAPI filter. However, unlike ASP.old, ASP.NET relies on a large number of "external" services--the .NET framework. ASP.NET and the .NET framework are so tightly coupled that it is difficult to consider the .NET framework as an external service. However, because it is accessible from applications outside the scope of ASP.NET, it should be considered an external service. As it turns out, this is a huge win for the ASP.NET developer. No longer must the developer write everything from scratch. Instead the .NET framework provides a large library of prewritten functionality.

The .NET framework redistributable consists of three main parts: the Common Language Runtime, the .NET framework base classes, and ASP.NET.

Common Language Runtime

The Common Language Runtime (CLR) is the execution engine for .NET framework applications. However, despite the common misconception, it is not an interpreter. The .NET applications are fully compiled applications that use the CLR to provide a number of services at execution. These services include the following:

  • Code management (loading and execution)
  • Application memory isolation
  • Verification of type safety
  • Conversion of IL to native code
  • Access to metadata
  • Garbage collection
  • Enforcement of code access security
  • Exception handling
  • Interoperability
  • Automation of object layout
  • Support for debugging and profiling

The CLR is a platform that abstracts functionality from the operating system. In this sense, code written to target the CLR is "platform independent," provided that an implementation of the CLR is on the destination platform.

Managed Execution

The CLR isn't just a library or framework of functions that an executing program can call on. It interacts with running code on a number of levels. The loader provided by the CLR performs validation, security checks, and a number of other tasks each time a piece of code is loaded. Memory allocation and access are also controlled by the CLR. When you hear about "managed execution," this is what folks are speaking about--the interaction between the CLR and the executing code to produce reliable applications.

Cross-Language Interoperability

One of the most frustrating things with current COM or API-based development practices is that interfaces are usually written with a particular language consumer in mind. When writing a component to be consumed by a Visual Basic program, a developer will typically create the interfaces in a different fashion than if the component is intended to be consumed by a C least-common-denominator approach to developing the interface or must develop an interface for each consumer. This is clearly not the most productive way to write components. A second problem that most developers merely accept as normal today is that most components need to be written in a single language. If you create a component in C++ that exposes an employee object, you can't then inherit from that object in Visual Basic to create a Developer object. This means that typically a single language is chosen for most development projects to enable reuse.

.NET changes all this. Cross-language interoperability was built in from the start. All .NET languages must adhere to the Common Language Specification (CLS) that specifies the base level of functionality that each language must implement to play well with others. The CLS is written in such a way that each language can keep its unique flavor but still operate correctly with other languages within the CLR. The CLS includes a number of data types that all conforming languages must support. This restriction works to eliminate a common problem for developers: creating an interface that utilizes data types that another language doesn't support. It also supports both Binary as well as Source code inheritance, enabling the developer to create an Employee object in C# and inherit from it in Visual Basic.

What this means to you as a developer is that code reuse has become much simpler. As long as the code was written for .NET, you don't need to worry what language it was written in. In fact, the choice of language becomes more of a lifestyle choice than a capability choice. All languages in .NET are theoretically created equal, so you gain no performance or functionality benefit by using C# instead of VB. Use the language in which you are the most productive.

New Features in ASP.NET

Up to this point, all the features mentioned are gained because of the hosting of ASP.NET on top of the .NET framework. However, these features are just the tip of the iceberg. As mentioned previously, ASP.NET is a total rewrite, with significant features aside from the intrinsic .NET ones. We are going to give you an overview of the new features in ASP.NET and show how these features address the problems of separation of code and design, scripting languages, and state management.

Web Forms

Web Forms are Microsoft's attempt to solve the problem of the separation of code and design. ASP.NET now offers a code-behind model reminiscent of the forms designer in Visual Basic. This means that you can now place your code in a separate file and still interact with the page. This separation is done by providing a new event-driven model on top of page execution, as well as providing an object model on top of the HTML in the page. Instead of a top-to-bottom linear execution model, events are raised during the execution of a page. Your code sinks those events and responds to them by interacting with the object model that sits on top of the HTML. This quite neatly solves the issue of designers modifying the HTML and breaking code.

In addition to the new execution model, Microsoft has also created a new server-side control model. Unlike the lame Design Time Controls in Visual Interdev, these new models are incredibly useful encapsulations of common display paradigms. They do not introduce any browser dependencies and they run on the server, not the client. In the few cases where they emit browser-dependent code, they sniff the browser and degrade gracefully. More information on Web Forms can be found in Chapter 3, "Page Framework."

Web Services

As we move beyond the first and second generations of Web applications, it has become apparent that the paradigm of the Web can be extended to solve problems that predate it. In the past, businesses exchanged information using Electronic Data Interchange (EDI) over Value Added Networks (VANs). This worked well enough, but the cost of gaining access to a VAN as well as the complexity of implementing various industry specific EDI protocols excluded all but the largest companies from participating in the exchange of information.

Web services are a way to transfer the same types of information over the Internet (instead of expensive VANs) using industry standard protocols such as HTTP, XML, and TCP/IP. Web services are now so easy to create in .NET that individuals or businesses of any size should be able to play in this space. Web services aren't limited to replacing traditional EDI protocols. They open up many opportunities that EDI has never made inroads into. Jump ahead to Chapter 7, "Web Services," for more information.

Data Access

When ASP 1.0 first shipped, the data access story at Microsoft was in a state of flux. At the time, Remote Data Objects (RDO) was the technology of choice for Visual Basic developers. ActiveX Data Objects (ADO) was introduced with the shipment of Visual Basic 5.0 in February of 1997. It was intended to be a new data access model for all types of data and was paired with another new technology--OLE DB.

Although ADO was great for what it was designed for--connected data access--it fell short in the disconnected arena. Features were added in successive versions to allow it to work in a disconnected fashion. ADO 1.0 had no support for XML. ADO 1.0 could not predict the success of XML as a data description language when it was shipped, and XML support was cobbled onto later versions. Neither of these features were designed in from the beginning.

ADO.NET is a new data access technology taking advantage of all the things Microsoft learned with ADO, RDO, OLEDB, ODBC, and other preceding data-access implementations. It was designed from the beginning to be coupled very tightly to XML and work effectively in a disconnected fashion. For more information, see Chapter 12, "Creating Database Applications with ADO.NET."

Deployment

One of the perennial arguments among ASP developers was how much code to migrate into COM objects. Some writers advocated that all code living in COM objects and ASP should contain only a single-method call to invoke the COM object. Although this might have been great in theory, it eliminated one of the biggest strengths of ASP: the capability to rapidly create an application and make changes on-the-fly. With all the logic and HTML tied up in COM objects, a simple HTML tag change meant recompiling and redeploying the COM objects. The biggest problem in our minds lies with using this approach. COM objects are Dynamic Link Libraries (DLL) that are dynamically loaded by IIS. While loaded they cannot be replaced. To deploy a COM object, the developer needed to shut down IIS, shut down the MTS packages the COM object lived in, replace it, and then restart IIS. This summary is actually a simplification of the process, but you can see the problems that this technique brings to the fore. Each time a new version is deployed, the Web server must go down! The downtime this technique causes can be handled by creating Web farms and doing rolling upgrades; however, in a large Web farm this means a simple change can take literally hours to deploy as the new objects are rolled out.

With the code-behind model inherent in ASP.NET, this situation could have been exacerbated. Instead, Microsoft vastly simplified the deployment model. Components, now called assemblies, no longer require registration on a machine for deployment. Assemblies are the .NET equivalent of a COM object. They are self describing and contain a manifest that contains metadata about the assembly. The metadata includes the version, the assemblies it depends on, and potentially its security identity.

Deployment is as easy as copying the assemblies into a /bin directory in the application root. ASP.NET will notice that a new version has been copied over, and it will unload the old version and load the new version! Deployment becomes as simple as an XCOPY /S or a recursive FTP to upload the new files to the Web server. For more information, see Chapter 6, "Configuration and Deployment."

Configuration

In the past, all configuration information for ASP was stored as part of the IIS metabase. This was a binary file analogous to the registry that held all settings for IIS and ASP. The only ways to affect changes were to use the Internet Services Manager or to write scripts that utilized the Active Directory Services Interfaces (ADSI) to automate the changes. This process made it very difficult to synchronize the settings of multiple servers in a Web farm. ASP.NET introduces a new paradigm for all settings. Instead of being stored in the opaque metabase, they are now stored as a hierarchical set of XML configuration files. These files live in the application root and subdirectories. Therefore, now as a developer uses XCOPY to deploy source files, the settings are also deployed! Developers no longer need to write a bunch of configuration scripts. For more information, see Chapter 6.

State Management

State management has been vastly improved in ASP.NET. Now three options exist for maintaining state on the server. The classic ASP 3.0 method of in-memory state on a single server still exists. In addition, an out-of-process state server and a durable state option is stored in SQL Server. The other limitation of state services in ASP.old was the reliance on cookies for connecting users back to their state. ASP.NET introduces a new option for a cookieless state that performs URL munging to connect a user to state information. For more information, see Chapter 5, "State Management and Caching."

Caching

The reason most developers use ASP is to lend a dynamic nature to the Web. This could mean accessing back-end databases for data or perhaps pulling it in from nontraditional back ends. The problem with this dynamic content is that although developers can easily scale the Web tier using a scale-out methodology of multiple Web servers, this scaling is not as easily done in the data tier. Scale-out approaches for databases are just beginning to appear. Until these approaches are perfected, how can Web developers scale applications?

For data that changes infrequently, caching is a great solution. ASP.NET offers two forms of caching. Output caching takes an entire page and stores the executed results in memory for later delivery. Data caching takes items that were expensive to create, such as DataSets, and caches them on the server side. For more information see Chapter 5.

Debugging

Debugging ASP applications has always been difficult. Although remote debugging solutions were offered in previous versions of Visual Studio, precious few developers were able to get them to work consistently. Consequently, most debugging consisted of Response.Write statements littered throughout code or some type of logging mechanism that the developer created.

ASP.NET not only improves remote debugging and makes it consistent, it also offers a new Trace facility that is great for handling the types of things that logging or Response.Write were used for in the past. For more information see Chapter 4, "Debugging ASP.NET Applications."

Availability

Anybody that currently has a site on the Web knows that availability is key. If your site is down, a visitor can turn to a million others. Problem is--they might not come back!

ASP.NET has introduced a number of process controls that are aimed directly at improving availability. Now the ASP.NET process can restart automatically based on things such as memory utilization, time up, or even the number of requests handled, which helps cope with situations where ASP used to get jammed up. For more information see Chapter 6.



Read More Show Less

Table of Contents

1 Introduction 1
2 Migrating from ASP to ASP.NET 11
3 Page Framework 51
4 Debugging ASP.NET Applications 149
5 State Management and Caching 169
6 Configuration and Deployment 219
7 Web Services 249
8 Security 301
9 HttpHandlers and HttpModules 351
10 Building User Controls and Server Controls 387
11 Using XML 421
12 Creating Database Applications with ADO.NET 483
Index 547
Read More Show Less

Preface

Problems with ASP Today

When Active Server Pages (ASP) was first introduced almost five years ago, it was seen as an answer to the awkward techniques used at that time for creating dynamic content on the Web. At the time, Common Gateway Interface programs or proprietary server plug-ins were the way that most of the Web's dynamic content was created. With the release of ASP 1.0, Microsoft changed all that. ASP 1.0 provided a flexible, robust scripting architecture that enabled developers to rapidly create dynamic Web applications. Developers could write in VBScript or JScript, and Microsoft provided a number of services to make development easy. At the time, it was just what developers needed. As Web development matured, several shortcomings of the platform became evident and persist until today.

Separation of Code and Design

As the Web grew in popularity in the early '90s, developers experienced three distinct waves of development paradigms. In the first wave, Web developers created static HTML documents and linked them. This was the era of the "brochure" Web site and was more about looks than anything else. The second wave brought the concept of dynamic content to the fore. Developers started creating registration forms and various small pieces of functionality and adding them to existing Web sites. The third wave was when the first and second waves came together. Web sites were being designed from the ground up to be interactive; they were treated more like an application and less like a magazine with a subscription card in it. In most instances, this type of interactive page design created a development paradigm that went like so:

  • Designers created page mockups in HTML.
  • Developers added code to the pages.
  • When designers needed to change their design, they copied and pasted the existing code into the new page, butchering it and destroying its functionality.

The severity of this problem typically depended on the size of the site, the smarts of the designers, and the techniques that developers used to guard against this mangling.

With the release of Visual Studio 6 in September of 1998, it was clear that Microsoft recognized this burgeoning problem and attempted to resolve it with a new feature in Visual Basic 6--Web Classes. Web Classes made an attempt to separate the design of a page from the code that interacted with it. It enabled this separation by using an HTML template and providing a facility for doing tag replacement in the template. However, a number of problems occurred with Web Classes. Although a great idea, they suffered from two main issues. First, the Web Classes were implemented entirely in Visual Basic, which required traditional ASP developers to shift their thinking patterns for creating applications. Second, Microsoft had scalability issues related to the threading models of ASP and Visual Basic. Because of the previously stated reasons and many other smaller ones, Web Classes never really gained any traction among developers.

Scripting Language Based

When ASP 1.0 was first released, the fact that all development was done using scripting languages was a big plus. It meant that developers didn't have to go through a painful restart/compile process that they might have been accustomed to with CGI or ISAPI style applications. As applications grew larger, numbers of users increased, and developers were using ASP for increasingly difficult problems. The fact that all code was interpreted became a potential performance bottleneck. With VBScript, limited support existed for error handling.

Many developers sidestepped this issue by moving code into compiled COM objects. Although this move solved some of the performance problems, it created new ones in deployment and scalability.

State Management

One of the most frustrating aspects that new Web developers faced early was dealing with the stateless nature of Web development. With ASP 1.0, Microsoft introduced the concept of a Session object, which was designed to make associating state with a particular user easy. This addition was arguably one of the most compelling features of ASP 1.0. Scalability and reliability started to become important as developers began creating larger applications. To address this need, developers started deploying their applications to Web farms. Web farms use multiple servers and spread the request for pages across the servers somewhat equally. This makes for a great scalability story... unless the developer is using that cool Session object. This object is specific to a particular machine in a Web farm and will not work if a user gets bounced to another server. Therefore, an application that was deployed to a Web farm could not use the Session object.

Introducing ASP.NET

ASP.NET is Microsoft's answer to the aforementioned problems and many others that were not explicitly stated. It is a fundamental rewrite of ASP that has been in process for more than two years. The ASP team took a close look at the problems facing Web developers and created a brand-new platform in the spirit of traditional ASP to solve those problems. Having used ASP.NET for a considerable amount of time, we can conclusively say they hit a home run with this release.

Platform Architecture

ASP.OLD was an Internet Server Application Programming Interface (ISAPI) filter that was written specifically to interact with Internet Information Server (IIS). It was monolithic in nature and relied very little on external services.

Note:In the IIS 5.0 time frame, ASP did use Microsoft Transaction Server (MTS) as an external service.

ASP.NET is still an ISAPI filter. However, unlike ASP.old, ASP.NET relies on a large number of "external" services--the .NET framework. ASP.NET and the .NET framework are so tightly coupled that it is difficult to consider the .NET framework as an external service. However, because it is accessible from applications outside the scope of ASP.NET, it should be considered an external service. As it turns out, this is a huge win for the ASP.NET developer. No longer must the developer write everything from scratch. Instead the .NET framework provides a large library of prewritten functionality.

The .NET framework redistributable consists of three main parts: the Common Language Runtime, the .NET framework base classes, and ASP.NET.

Common Language Runtime

The Common Language Runtime (CLR) is the execution engine for .NET framework applications. However, despite the common misconception, it is not an interpreter. The .NET applications are fully compiled applications that use the CLR to provide a number of services at execution. These services include the following:

  • Code management (loading and execution)
  • Application memory isolation
  • Verification of type safety
  • Conversion of IL to native code
  • Access to metadata
  • Garbage collection
  • Enforcement of code access security
  • Exception handling
  • Interoperability
  • Automation of object layout
  • Support for debugging and profiling

The CLR is a platform that abstracts functionality from the operating system. In this sense, code written to target the CLR is "platform independent," provided that an implementation of the CLR is on the destination platform.

Managed Execution

The CLR isn't just a library or framework of functions that an executing program can call on. It interacts with running code on a number of levels. The loader provided by the CLR performs validation, security checks, and a number of other tasks each time a piece of code is loaded. Memory allocation and access are also controlled by the CLR. When you hear about "managed execution," this is what folks are speaking about--the interaction between the CLR and the executing code to produce reliable applications.

Cross-Language Interoperability

One of the most frustrating things with current COM or API-based development practices is that interfaces are usually written with a particular language consumer in mind. When writing a component to be consumed by a Visual Basic program, a developer will typically create the interfaces in a different fashion than if the component is intended to be consumed by a C++ program. This means that to reach both audiences, the developer must either use a least-common-denominator approach to developing the interface or must develop an interface for each consumer. This is clearly not the most productive way to write components. A second problem that most developers merely accept as normal today is that most components need to be written in a single language. If you create a component in C++ that exposes an employee object, you can't then inherit from that object in Visual Basic to create a Developer object. This means that typically a single language is chosen for most development projects to enable reuse.

.NET changes all this. Cross-language interoperability was built in from the start. All .NET languages must adhere to the Common Language Specification (CLS) that specifies the base level of functionality that each language must implement to play well with others. The CLS is written in such a way that each language can keep its unique flavor but still operate correctly with other languages within the CLR. The CLS includes a number of data types that all conforming languages must support. This restriction works to eliminate a common problem for developers: creating an interface that utilizes data types that another language doesn't support. It also supports both Binary as well as Source code inheritance, enabling the developer to create an Employee object in C# and inherit from it in Visual Basic.

What this means to you as a developer is that code reuse has become much simpler. As long as the code was written for .NET, you don't need to worry what language it was written in. In fact, the choice of language becomes more of a lifestyle choice than a capability choice. All languages in .NET are theoretically created equal, so you gain no performance or functionality benefit by using C# instead of VB. Use the language in which you are the most productive.

New Features in ASP.NET

Up to this point, all the features mentioned are gained because of the hosting of ASP.NET on top of the .NET framework. However, these features are just the tip of the iceberg. As mentioned previously, ASP.NET is a total rewrite, with significant features aside from the intrinsic .NET ones. We are going to give you an overview of the new features in ASP.NET and show how these features address the problems of separation of code and design, scripting languages, and state management.

Web Forms

Web Forms are Microsoft's attempt to solve the problem of the separation of code and design. ASP.NET now offers a code-behind model reminiscent of the forms designer in Visual Basic. This means that you can now place your code in a separate file and still interact with the page. This separation is done by providing a new event-driven model on top of page execution, as well as providing an object model on top of the HTML in the page. Instead of a top-to-bottom linear execution model, events are raised during the execution of a page. Your code sinks those events and responds to them by interacting with the object model that sits on top of the HTML. This quite neatly solves the issue of designers modifying the HTML and breaking code.

In addition to the new execution model, Microsoft has also created a new server-side control model. Unlike the lame Design Time Controls in Visual Interdev, these new models are incredibly useful encapsulations of common display paradigms. They do not introduce any browser dependencies and they run on the server, not the client. In the few cases where they emit browser-dependent code, they sniff the browser and degrade gracefully. More information on Web Forms can be found in Chapter 3, "Page Framework."

Web Services

As we move beyond the first and second generations of Web applications, it has become apparent that the paradigm of the Web can be extended to solve problems that predate it. In the past, businesses exchanged information using Electronic Data Interchange (EDI) over Value Added Networks (VANs). This worked well enough, but the cost of gaining access to a VAN as well as the complexity of implementing various industry specific EDI protocols excluded all but the largest companies from participating in the exchange of information.

Web services are a way to transfer the same types of information over the Internet (instead of expensive VANs) using industry standard protocols such as HTTP, XML, and TCP/IP. Web services are now so easy to create in .NET that individuals or businesses of any size should be able to play in this space. Web services aren't limited to replacing traditional EDI protocols. They open up many opportunities that EDI has never made inroads into. Jump ahead to Chapter 7, "Web Services," for more information.

Data Access

When ASP 1.0 first shipped, the data access story at Microsoft was in a state of flux. At the time, Remote Data Objects (RDO) was the technology of choice for Visual Basic developers. ActiveX Data Objects (ADO) was introduced with the shipment of Visual Basic 5.0 in February of 1997. It was intended to be a new data access model for all types of data and was paired with another new technology--OLE DB.

Although ADO was great for what it was designed for--connected data access--it fell short in the disconnected arena. Features were added in successive versions to allow it to work in a disconnected fashion. ADO 1.0 had no support for XML. ADO 1.0 could not predict the success of XML as a data description language when it was shipped, and XML support was cobbled onto later versions. Neither of these features were designed in from the beginning.

ADO.NET is a new data access technology taking advantage of all the things Microsoft learned with ADO, RDO, OLEDB, ODBC, and other preceding data-access implementations. It was designed from the beginning to be coupled very tightly to XML and work effectively in a disconnected fashion. For more information, see Chapter 12, "Creating Database Applications with ADO.NET."

Deployment

One of the perennial arguments among ASP developers was how much code to migrate into COM objects. Some writers advocated that all code living in COM objects and ASP should contain only a single-method call to invoke the COM object. Although this might have been great in theory, it eliminated one of the biggest strengths of ASP: the capability to rapidly create an application and make changes on-the-fly. With all the logic and HTML tied up in COM objects, a simple HTML tag change meant recompiling and redeploying the COM objects. The biggest problem in our minds lies with using this approach. COM objects are Dynamic Link Libraries (DLL) that are dynamically loaded by IIS. While loaded they cannot be replaced. To deploy a COM object, the developer needed to shut down IIS, shut down the MTS packages the COM object lived in, replace it, and then restart IIS. This summary is actually a simplification of the process, but you can see the problems that this technique brings to the fore. Each time a new version is deployed, the Web server must go down! The downtime this technique causes can be handled by creating Web farms and doing rolling upgrades; however, in a large Web farm this means a simple change can take literally hours to deploy as the new objects are rolled out.

With the code-behind model inherent in ASP.NET, this situation could have been exacerbated. Instead, Microsoft vastly simplified the deployment model. Components, now called assemblies, no longer require registration on a machine for deployment. Assemblies are the .NET equivalent of a COM object. They are self describing and contain a manifest that contains metadata about the assembly. The metadata includes the version, the assemblies it depends on, and potentially its security identity.

Deployment is as easy as copying the assemblies into a /bin directory in the application root. ASP.NET will notice that a new version has been copied over, and it will unload the old version and load the new version! Deployment becomes as simple as an XCOPY /S or a recursive FTP to upload the new files to the Web server. For more information, see Chapter 6, "Configuration and Deployment."

Configuration

In the past, all configuration information for ASP was stored as part of the IIS metabase. This was a binary file analogous to the registry that held all settings for IIS and ASP. The only ways to affect changes were to use the Internet Services Manager or to write scripts that utilized the Active Directory Services Interfaces (ADSI) to automate the changes. This process made it very difficult to synchronize the settings of multiple servers in a Web farm. ASP.NET introduces a new paradigm for all settings. Instead of being stored in the opaque metabase, they are now stored as a hierarchical set of XML configuration files. These files live in the application root and subdirectories. Therefore, now as a developer uses XCOPY to deploy source files, the settings are also deployed! Developers no longer need to write a bunch of configuration scripts. For more information, see Chapter 6.

State Management

State management has been vastly improved in ASP.NET. Now three options exist for maintaining state on the server. The classic ASP 3.0 method of in-memory state on a single server still exists. In addition, an out-of-process state server and a durable state option is stored in SQL Server. The other limitation of state services in ASP.old was the reliance on cookies for connecting users back to their state. ASP.NET introduces a new option for a cookieless state that performs URL munging to connect a user to state information. For more information, see Chapter 5, "State Management and Caching."

Caching

The reason most developers use ASP is to lend a dynamic nature to the Web. This could mean accessing back-end databases for data or perhaps pulling it in from nontraditional back ends. The problem with this dynamic content is that although developers can easily scale the Web tier using a scale-out methodology of multiple Web servers, this scaling is not as easily done in the data tier. Scale-out approaches for databases are just beginning to appear. Until these approaches are perfected, how can Web developers scale applications?

For data that changes infrequently, caching is a great solution. ASP.NET offers two forms of caching. Output caching takes an entire page and stores the executed results in memory for later delivery. Data caching takes items that were expensive to create, such as DataSets, and caches them on the server side. For more information see Chapter 5.

Debugging

Debugging ASP applications has always been difficult. Although remote debugging solutions were offered in previous versions of Visual Studio, precious few developers were able to get them to work consistently. Consequently, most debugging consisted of Response.Write statements littered throughout code or some type of logging mechanism that the developer created.

ASP.NET not only improves remote debugging and makes it consistent, it also offers a new Trace facility that is great for handling the types of things that logging or Response.Write were used for in the past. For more information see Chapter 4, "Debugging ASP.NET Applications."

Availability

Anybody that currently has a site on the Web knows that availability is key. If your site is down, a visitor can turn to a million others. Problem is--they might not come back!

ASP.NET has introduced a number of process controls that are aimed directly at improving availability. Now the ASP.NET process can restart automatically based on things such as memory utilization, time up, or even the number of requests handled, which helps cope with situations where ASP used to get jammed up. For more information see Chapter 6.

0672321319P03252002

Read More Show Less

Introduction

Problems with ASP Today

When Active Server Pages (ASP) was first introduced almost five years ago, it was seen as an answer to the awkward techniques used at that time for creating dynamic content on the Web. At the time, Common Gateway Interface programs or proprietary server plug-ins were the way that most of the Web's dynamic content was created. With the release of ASP 1.0, Microsoft changed all that. ASP 1.0 provided a flexible, robust scripting architecture that enabled developers to rapidly create dynamic Web applications. Developers could write in VBScript or JScript, and Microsoft provided a number of services to make development easy. At the time, it was just what developers needed. As Web development matured, several shortcomings of the platform became evident and persist until today.

Separation of Code and Design

As the Web grew in popularity in the early '90s, developers experienced three distinct waves of development paradigms. In the first wave, Web developers created static HTML documents and linked them. This was the era of the "brochure" Web site and was more about looks than anything else. The second wave brought the concept of dynamic content to the fore. Developers started creating registration forms and various small pieces of functionality and adding them to existing Web sites. The third wave was when the first and second waves came together. Web sites were being designed from the ground up to be interactive; they were treated more like an application and less like a magazine with a subscription card in it. In most instances, this type of interactive page design created a development paradigm that went like so:

  • Designers created page mockups in HTML.
  • Developers added code to the pages.
  • When designers needed to change their design, they copied and pasted the existing code into the new page, butchering it and destroying its functionality.

The severity of this problem typically depended on the size of the site, the smarts of the designers, and the techniques that developers used to guard against this mangling.

With the release of Visual Studio 6 in September of 1998, it was clear that Microsoft recognized this burgeoning problem and attempted to resolve it with a new feature in Visual Basic 6—Web Classes. Web Classes made an attempt to separate the design of a page from the code that interacted with it. It enabled this separation by using an HTML template and providing a facility for doing tag replacement in the template. However, a number of problems occurred with Web Classes. Although a great idea, they suffered from two main issues. First, the Web Classes were implemented entirely in Visual Basic, which required traditional ASP developers to shift their thinking patterns for creating applications. Second, Microsoft had scalability issues related to the threading models of ASP and Visual Basic. Because of the previously stated reasons and many other smaller ones, Web Classes never really gained any traction among developers.

Scripting Language Based

When ASP 1.0 was first released, the fact that all development was done using scripting languages was a big plus. It meant that developers didn't have to go through a painful restart/compile process that they might have been accustomed to with CGI or ISAPI style applicatio applications grew larger, numbers of users increased, and developers were using ASP for increasingly difficult problems. The fact that all code was interpreted became a potential performance bottleneck. With VBScript, limited support existed for error handling.

Many developers sidestepped this issue by moving code into compiled COM objects. Although this move solved some of the performance problems, it created new ones in deployment and scalability.

State Management

One of the most frustrating aspects that new Web developers faced early was dealing with the stateless nature of Web development. With ASP 1.0, Microsoft introduced the concept of a Session object, which was designed to make associating state with a particular user easy. This addition was arguably one of the most compelling features of ASP 1.0. Scalability and reliability started to become important as developers began creating larger applications. To address this need, developers started deploying their applications to Web farms. Web farms use multiple servers and spread the request for pages across the servers somewhat equally. This makes for a great scalability story... unless the developer is using that cool Session object. This object is specific to a particular machine in a Web farm and will not work if a user gets bounced to another server. Therefore, an application that was deployed to a Web farm could not use the Session object.

Introducing ASP.NET

ASP.NET is Microsoft's answer to the aforementioned problems and many others that were not explicitly stated. It is a fundamental rewrite of ASP that has been in process for more than two years. The ASP team took a close look at the problems facing Web developers and created a brand-new platform in the spirit of traditional ASP to solve those problems. Having used ASP.NET for a considerable amount of time, we can conclusively say they hit a home run with this release.

Platform Architecture

ASP.OLD was an Internet Server Application Programming Interface (ISAPI) filter that was written specifically to interact with Internet Information Server (IIS). It was monolithic in nature and relied very little on external services.

Note:In the IIS 5.0 time frame, ASP did use Microsoft Transaction Server (MTS) as an external service.

ASP.NET is still an ISAPI filter. However, unlike ASP.old, ASP.NET relies on a large number of "external" services—the .NET framework. ASP.NET and the .NET framework are so tightly coupled that it is difficult to consider the .NET framework as an external service. However, because it is accessible from applications outside the scope of ASP.NET, it should be considered an external service. As it turns out, this is a huge win for the ASP.NET developer. No longer must the developer write everything from scratch. Instead the .NET framework provides a large library of prewritten functionality.

The .NET framework redistributable consists of three main parts: the Common Language Runtime, the .NET framework base classes, and ASP.NET.

Common Language Runtime

The Common Language Runtime (CLR) is the execution engine for .NET framework applications. However, despite the common misconception, it is not an interpreter. The .NET applications are fully compiled applications that use the CLR to provide a number of services at execution. These services include the following:

  • Code management (loading and execution)
  • Application memory isolation
  • Verification of type safety
  • Conversion of IL to native code
  • Access to metadata
  • Garbage collection
  • Enforcement of code access security
  • Exception handling
  • Interoperability
  • Automation of object layout
  • Support for debugging and profiling

The CLR is a platform that abstracts functionality from the operating system. In this sense, code written to target the CLR is "platform independent," provided that an implementation of the CLR is on the destination platform.

Managed Execution

The CLR isn't just a library or framework of functions that an executing program can call on. It interacts with running code on a number of levels. The loader provided by the CLR performs validation, security checks, and a number of other tasks each time a piece of code is loaded. Memory allocation and access are also controlled by the CLR. When you hear about "managed execution," this is what folks are speaking about—the interaction between the CLR and the executing code to produce reliable applications.

Cross-Language Interoperability

One of the most frustrating things with current COM or API-based development practices is that interfaces are usually written with a particular language consumer in mind. When writing a component to be consumed by a Visual Basic program, a developer will typically create the interfaces in a different fashion than if the co audiences, the developer must either use a least-common-denominator approach to developing the interface or must develop an interface for each consumer. This is clearly not the most productive way to write components. A second problem that most developers merely accept as normal today is that most components need to be written in a single language. If you create a component in C++ that exposes an employee object, you can't then inherit from that object in Visual Basic to create a Developer object. This means that typically a single language is chosen for most development projects to enable reuse.

.NET changes all this. Cross-language interoperability was built in from the start. All .NET languages must adhere to the Common Language Specification (CLS) that specifies the base level of functionality that each language must implement to play well with others. The CLS is written in such a way that each language can keep its unique flavor but still operate correctly with other languages within the CLR. The CLS includes a number of data types that all conforming languages must support. This restriction works to eliminate a common problem for developers: creating an interface that utilizes data types that another language doesn't support. It also supports both Binary as well as Source code inheritance, enabling the developer to create an Employee object in C# and inherit from it in Visual Basic.

What this means to you as a developer is that code reuse has become much simpler. As long as the code was written for .NET, you don't need to worry what language it was written in. In fact, the choice of language becomes more of a lifestyle choice than a capability choice. All languages in .NET are theoretically created equal, so you gain no performance or functionality benefit by using C# instead of VB. Use the language in which you are the most productive.

New Features in ASP.NET

Up to this point, all the features mentioned are gained because of the hosting of ASP.NET on top of the .NET framework. However, these features are just the tip of the iceberg. As mentioned previously, ASP.NET is a total rewrite, with significant features aside from the intrinsic .NET ones. We are going to give you an overview of the new features in ASP.NET and show how these features address the problems of separation of code and design, scripting languages, and state management.

Web Forms

Web Forms are Microsoft's attempt to solve the problem of the separation of code and design. ASP.NET now offers a code-behind model reminiscent of the forms designer in Visual Basic. This means that you can now place your code in a separate file and still interact with the page. This separation is done by providing a new event-driven model on top of page execution, as well as providing an object model on top of the HTML in the page. Instead of a top-to-bottom linear execution model, events are raised during the execution of a page. Your code sinks those events and responds to them by interacting with the object model that sits on top of the HTML. This quite neatly solves the issue of designers modifying the HTML and breaking code.

In addition to the new execution model, Microsoft has also created a new server-side control model. Unlike the lame Design Time Controls in Visual Interdev, these new models are incredibly useful encapsulations of common display paradigms. They do not introduce any browser dependencies and they run on the server, not the client. In the few cases where they emit browser-dependent code, they sniff the browser and degrade gracefully. More information on Web Forms can be found in Chapter 3, "Page Framework."

Web Services

As we move beyond the first and second generations of Web applications, it has become apparent that the paradigm of the Web can be extended to solve problems that predate it. In the past, businesses exchanged information using Electronic Data Interchange (EDI) over Value Added Networks (VANs). This worked well enough, but the cost of gaining access to a VAN as well as the complexity of implementing various industry specific EDI protocols excluded all but the largest companies from participating in the exchange of information.

Web services are a way to transfer the same types of information over the Internet (instead of expensive VANs) using industry standard protocols such as HTTP, XML, and TCP/IP. Web services are now so easy to create in .NET that individuals or businesses of any size should be able to play in this space. Web services aren't limited to replacing traditional EDI protocols. They open up many opportunities that EDI has never made inroads into. Jump ahead to Chapter 7, "Web Services," for more information.

Data Access

When ASP 1.0 first shipped, the data access story at Microsoft was in a state of flux. At the time, Remote Data Objects (RDO) was the technology of choice for Visual Basic developers. ActiveX Data Objects (ADO) was introduced with the shipment of Visual Basic 5.0 in February of 1997. It was intended to be a new data access model for all types of data and was paired with another new technology—OLE DB.

Although ADO was great for what it was designed for—connected data access—it fell short in the disconnected arena. Features were added in successive versions to allow it to work in a disconnected fashion. ADO 1.0 had no support for XML. ADO 1.0 could not predict the success of XML as a data description language when it was shipped, and XML support was cobbled onto later versions. Neither of these features were designed in from the beginning.

ADO.NET is a new data access technology taking advantage of all the things Microsoft learned with ADO, RDO, OLEDB, ODBC, and other preceding data-access implementations. It was designed from the beginning to be coupled very tightly to XML and work effectively in a disconnected fashion. For more information, see Chapter 12, "Creating Database Applications with ADO.NET."

Deployment

One of the perennial arguments among ASP developers was how much code to migrate into COM objects. Some writers advocated that all code living in COM objects and ASP should contain only a single-method call to invoke the COM object. Although this might have been great in theory, it eliminated one of the biggest strengths of ASP: the capability to rapidly create an application and make changes on-the-fly. With all the logic and HTML tied up in COM objects, a simple HTML tag change meant recompiling and redeploying the COM objects. The biggest problem in our minds lies with using this approach. COM objects are Dynamic Link Libraries (DLL) that are dynamically loaded by IIS. While loaded they cannot be replaced. To deploy a COM object, the developer needed to shut down IIS, shut down the MTS packages the COM object lived in, replace it, and then restart IIS. This summary is actually a simplification of the process, but you can see the problems that this technique brings to the fore. Each time a new version is deployed, the Web server must go down! The downtime this technique causes can be handled by creating Web farms and doing rolling upgrades; however, in a large Web farm this means a simple change can take literally hours to deploy as the new objects are rolled out.

With the code-behind model inherent in ASP.NET, this situation could have been exacerbated. Instead, Microsoft vastly simplified the deployment model. Components, now called assemblies, no longer require registration on a machine for deployment. Assemblies are the .NET equivalent of a COM object. They are self describing and contain a manifest that contains metadata about the assembly. The metadata includes the version, the assemblies it depends on, and potentially its security identity.

Deployment is as easy as copying the assemblies into a /bin directory in the application root. ASP.NET will notice that a new version has been copied over, and it will unload the old version and load the new version! Deployment becomes as simple as an XCOPY /S or a recursive FTP to upload the new files to the Web server. For more information, see Chapter 6, "Configuration and Deployment."

Configuration

In the past, all configuration information for ASP was stored as part of the IIS metabase. This was a binary file analogous to the registry that held all settings for IIS and ASP. The only ways to affect changes were to use the Internet Services Manager or to write scripts that utilized the Active Directory Services Interfaces (ADSI) to automate the changes. This process made it very difficult to synchronize the settings of multiple servers in a Web farm. ASP.NET introduces a new paradigm for all settings. Instead of being stored in the opaque metabase, they are now stored as a hierarchical set of XML configuration files. These files live in the application root and subdirectories. Therefore, now as a developer uses XCOPY to deploy source files, the settings are also deployed! Developers no longer need to write a bunch of configuration scripts. For more information, see Chapter 6.

State Management

State management has been vastly improved in ASP.NET. Now three options exist for maintaining state on the server. The classic ASP 3.0 method of in-memory state on a single server still exists. In addition, an out-of-process state server and a durable state option is stored in SQL Server. The other limitation of state services in ASP.old was the reliance on cookies for connecting users back to their state. ASP.NET introduces a new option for a cookieless state that performs URL munging to connect a user to state information. For more information, see Chapter 5, "State Management and Caching."

Caching

The reason most developers use ASP is to lend a dynamic nature to the Web. This could mean accessing back-end databases for data or perhaps pulling it in from nontraditional back ends. The problem with this dynamic content is that although developers can easily scale the Web tier using a scale-out methodology of multiple Web servers, this scaling is not as easily done in the data tier. Scale-out approaches for databases are just beginning to appear. Until these approaches are perfected, how can Web developers scale applications?

For data that changes infrequently, caching is a great solution. ASP.NET offers two forms of caching. Output caching takes an entire page and stores the executed results in memory for later delivery. Data caching takes items that were expensive to create, such as DataSets, and caches them on the server side. For more information see Chapter 5.

Debugging

Debugging ASP applications has always been difficult. Although remote debugging solutions were offered in previous versions of Visual Studio, precious few developers were able to get them to work consistently. Consequently, most debugging consisted of Response.Write statements littered throughout code or some type of logging mechanism that the developer created.

ASP.NET not only improves remote debugging and makes it consistent, it also offers a new Trace facility that is great for handling the types of things that logging or Response.Write were used for in the past. For more information see Chapter 4, "Debugging ASP.NET Applications."

Availability

Anybody that currently has a site on the Web knows that availability is key. If your site is down, a visitor can turn to a million others. Problem is—they might not come back!

ASP.NET has introduced a number of process controls that are aimed directly at improving availability. Now the ASP.NET process can restart automatically based on things such as memory utilization, time up, or even the number of requests handled, which helps cope with situations where ASP used to get jammed up. For more information see Chapter 6.



Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)