Datasheet

When most developers think of “objects” they think of middleware components— items used to
encapsulate business logic and data access that are called from the application code to perform some
task. One example of these kinds of objects is the ADO.NET objects that are used in .NET to retrieve and
update data (or the DAO and ADO objects in the COM world). There are two fundamental differences
between that definition of objects and the ASP.NET-specific tools (custom controls, user controls, and
Web Parts).
The first difference is that ASP.NET custom controls, user controls, and Web Parts can be used only
with ASP.NET. The ADO.NET objects, for instance, can be accessed from any kind of code. It doesn’t
matter if your code is in a Windows Form, an ASP.NET page, or a middle-tier object, you can use the
ADO.NET objects. However, limiting user controls, custom controls, and Web Parts to ASP.NET has its
compensations: the ASP.NET tools, because they are tailored to ASP.NET, leverage the capabilities of the
ASP.NET environment.
The second difference between the ASP.NET tools and what most developers think of as “objects” is where
the ASP.NET tools are used. Most of the objects that developers create are designed to implement business
logic and to reside in an application’s middle tier— between the presentation layer (the user interface)
and the data layer (the database). As part of creating a sales order system, for instance, a developer might
create Customer, SalesOrder, and Invoice objects to handle all the activities involved with managing the
application data. These objects would be called from code in the application’s user interface and, in turn,
update the application data in the database.
The ASP.NET tools, however, work only in the presentation layer, where they become an integral part
of the user interface. In terms of the three benefits of using objects (productivity, standardization,
simplification), the ASP.NET tools allow you to create a consistent user experience across many Web
pages (and, with custom controls/Web Parts, across many Web sites). In addition, middle-tier objects
can execute only on the Web server and are accessible only from application code that executes on your
Web server. Web Parts, on the other hand, support writing code that will execute on both the server and
in the browser, on the client. With the ASP.NET tools you can include client-side code that will be added
to the HTML page that goes to the user and, as a result, executes in the Web browser.
Controls in Action
As an example of using controls to implement reusability in a user interface, consider a Web-based
application that allows users to browse a catalog of books and order books. A user can log on to the
application, search for a book by a list of criteria, read the details on a book, and place an order. Before they
can access the site, users must register by entering information about themselves. In addition, when buying
a book a customer must enter (or review and confirm) her billing, shipping, and contact information.
In this book application, users can list books in many different ways (for instance, wish lists, gift registries,
recommended books, reminder lists). The application supports a variety of different customer types (such
as individual consumers, companies, or libraries) and a variety of ways for customers to order books
(individual orders, bulk orders, recurring orders, and so on). Customers can buy books using several
different purchase mechanisms such as credit card, check, or purchase orders. Refer to Figure 1-2 to see
typical pages from the bookstore Web site, listing books that match criteria entered by the user.
10
Chapter 1
05_57860x ch01.qxd 10/4/05 9:26 PM Page 10