Chapter 2: ASP.NET Namespaces (ASP.NET Web Developer's Guide, Syngress Publishing)

Enabling Client/Browser Communication with the System.Web Namespace

Perhaps one of the most important namespace for ASP.NET, the System.Web namespace contains most of the functionality for building ASP.NET pages. You'll be covering the classes and functionality of this namespace extensively in later chapters (you'll have to, in order to learn ASP.NET!), so we'll only touch on its members here.

Supplied Functionality

Specifically, the System.Web interface provides the functionality that enables client/browser communication, which is key for ASP.NET pages. The System.Web.HttpResponse class encapsulates Hypertext Transfer Protocol (HTTP) response information. Likewise, the System.Web.HttpRequest object encapsulates HTTP values sent from a client.

In addition, you now have the HttpServerUtility object, which provides helper methods that parse HTTP information and return server variables.

Migrating…

Response and Request Objects

If you are familiar with classic ASP, the Response and Request objects should sound familiar to you. The Request and Response objects in ASP 3.0 are used for exactly the same functionality, and have most of the same methods as the new ASP.NET objects, such as the all-too-familiar Response.Write method.

In fact, ASP.NET makes it easy for you by enabling you to use the same names for these objects as previous versions of ASP. When an ASP.NET page is created, the Common Language Runtime (CLR) creates HttpResponse and HttpRequest object variables named Response and Request respectively. Thus, you can use Response.Write just as you did in classic ASP.

The HttpServerUtility is also instantiated as an object variable named Server. It contains all the familiar methods as well, such as Server.MapPath and Server.HTMLEncode.

These objects in ASP.NET are much more powerful, however, than their older counterparts. They are fully object-oriented, which means you can inherit or extend them, and they also provide a multitude of new methods and properties that will be useful for ASP.NET developers.

Note, however, that the Request and Response objects hearken back to the days of the Request/Response model of Internet communication. One of the main benefits of ASP.NET is that it abstracts this older model with an event-driven model, which allows for more intuitive application programming. In general, you'll want to use an event-driven method to interact with data rather than using Request or Response. For example, rather than using the following code snippet to display text to the user:

Response.Write("Hello World!")

You should use something like this:

lblText.Text = "Hello World!"

Where lblText is a label object in the UI.

This namespace also has classes for dealing with many common HTTP related functions: the HttpCookie object lets you create and read cookies; the HttpApplication class provides control over the ASP.NET application itself; HttpCachePolicy is used to set HTTP headers that specify how you can cache ASP.NET pages; and the HttpFileCollection class provides access to files uploaded by clients. There are quite a few other useful classes in this namespace as well—see the .NET Framework SDK Documentation for more information.

System.Web.UI Namespace Set

In the System.Web namespace, the System.Web.UI sub-namespace is probably the most used collection of objects in ASP.NET. It provides all the functionality you'll need to create, render, and display user interface (UI) elements to the end user.

The System.Web.UI.Control object is the base class for almost all of the UI objects you'll be using in ASP.NET. It provides methods and properties that are common to all ASP.NET server controls, thus making it easy to learn how each control works. Figure 2.3 shows the hierarchy of objects based on this class.

Figure 2.3 The Hierarchy of UI Objects

The System.Web.UI.HtmlControls and System.Web.UI.WebControls sub-namespaces provide the classes that render actual UI elements such as HTML input text boxes and forms. You'll learn more about these in Chapter 3. For example, Figure 2.3 shows the HTMLAnchor object in the System.Web.UI.HtmlControls namespace. The minimum amount of ASP.NET code that would utilize this object is shown in Figure 2.4.

Figure 2.4 Using Objects in the System.Web.UI Namespace

1: <%@ Page Language="VB" %>

3: <html><body>

4: <a href="blah.aspx" runat="server">Click me!</a>

5: </body></html>

This listing simply displays an anchor in the Web page, as shown in Figure 2.5. Notice that it looks just like a regular HTML page with the exception of the @Page and runat="server" attributes. The runat="server" tells ASP.NET that this control isn't just a normal HTML anchor, but rather an instance of the server object HTMLAnchor, which contains properties and methods. You can easily turn most HTML controls into their ASP.NET object counterparts simply by adding the runat="server" attribute.

Figure 2.5 A Simple HTMLAnchor Control

Using objects from the WebControls namespace is a bit different, but no more difficult. Figure 2.6 shows an example.

Figure 2.6 A TextBox Web Control

1: <%@ Page Language="VB" %>

3: <html><body>

4: <asp:TextBox value="Welcome to ASP.NET!" runat="server"/>

5: </body></html>

This syntax is a bit different than normal HTML, but is one that you'll be seeing very often in ASP.NET pages, as well as later in this book. Again notice the runat="server" on line 4—this attribute is vital for ASP.NET controls to function correctly. Without it, ASP.NET believes that you are just trying to create a customized tag that it doesn't recognize, and so it will just send it as is to the browser, which won't produce the right results. Figure 2.6 produces the result shown in Figure 2.7.

Figure 2.7 An ASP.NET TextBox Control

It is necessary to mention a subset of ASP.NET controls that deal with data, as they are very important in ASP.NET: the Repeater, DataList, and DataGrid controls. These controls have no specific counterparts in HTML, but rather present a complex UI consisting of HTML tables and lists. Any time you have a data source, you can simply bind it to these objects (you can actually bind data to any type of ASP.NET controls, but more on that in later chapters) and the object will provide the UI for you, no matter how complex it may be. Figure 2.8 shows an example of the DataGrid in action.

Figure 2.8 The DataGrid Web Control

The code to generate Figure 2.8 is shown in Figure 2.9.

Figure 2.9 Using a DataGrid Control in ASP.NET

1: <%@ Page Language="VB" %>

2: <%@ Import Namespace="System.Data" %>

3: <%@ Import Namespace="System.Data.SqlClient" %>

5: <script runat="server">

6: Sub Page_Load(Src As Object, e As EventArgs)

7: Dim myConnection As SqlConnection

8: Dim myCommand As SqlDataAdapter

10: myConnection = new _

11: SqlConnection("server=localhost;uid=sa;pwd=;" _

12: & "database=pubs")

13: myCommand = new SqlDataAdapter("SELECT * FROM Authors", _

14: myConnection)

15:

16: Dim ds As DataSet = new DataSet()

17: myCommand.Fill(ds)

18:

19: MyDataGrid.DataSource = ds

20: MyDataGrid.DataBind()

21: End Sub

22: </script>

23:

24: <html><body>

25: <h3><font face="Verdana">

26: Simple Select to a DataGrid Control.

27: </font></h3>

28: <ASP:DataGrid id="MyDataGrid" runat="server"

29: Width="700"

30: BackColor="#ccccff"

31: BorderColor="black"

32: ShowFooter="false"

33: CellPadding=3

34: CellSpacing="0"

35: Font-Name="Verdana"

36: Font-Size="8pt"

37: HeaderStyle-BackColor="#aaaadd"

38: MaintainState="false"

39: />

40: </body></html>

You can see that there is no code to loop through any data. Simply assign the DataGrid a data source, as shown on line 19, call the DataBind method, and you're set to go!

System.Web.Services Namespace Set

Web services are a new feature to ASP.NET. They enable anyone to access your application over the Internet, just as if it were on their local machine. For example, Microsoft could maintain one copy of Microsoft Office on their servers, and when you need to run Word, you could just connect to their servers and run it like normal. Web services promise a lot of benefits for both clients and developers.

Web services enable you to do this because they are based on existing, non-proprietary standards such as XML and Simple Object Access Protocol (SOAP). Using these protocols, a Web service client communicates with the Web service over the Internet, sending commands and data back and forth as plain XML. This means that such applications can work even across firewalls. Figure 2.10 illustrates this process; note that both Web service and client can be ASP.NET pages, as well as traditional applications.

Figure 2.10 How a Web Service Works

When the Web service on the server receives a command, it processes it just as if it were a local application. The server can access databases, local files, user lists, or even other Web services. Any data that needs to be returned is then sent back to the client as XML.

You may be wondering how this is different than regular ASP.NET pages. First, ASP.NET pages usually require a UI—a Web service does not. It simply provides functionality that another application can take advantage of. The second difference is that any application can use a Web service, from an ASP.NET page to a desktop-based calculator. ASP.NET pages have to be served up through a Web server. Don't think, however, that Web services are a replacement for ASP.NET pages—each technology simply provides different functionality for different situations.

Working with Data Sources Using the System.Data Namespace

The System.Data namespace contains most of the objects associated with ADO.NET, such as DataReaders and DataSets. These objects enable you to interface with all sorts of data sources, from text files to Microsoft SQL Server, to Oracle, or even with custom data sources you create yourself. You'll be spending a large amount of time dealing with ADO.NET in Chapter 7 and in subsequent chapters.

Supplied Functionality

Any time you need to deal with an outside data source, you'll likely use objects in the System.Data namespace. One of the most important classes in this namespace is the DataSet. It provides a complete, disconnected representation of any data source, whether a traditional database, an XML file, or even a file system. As you start building data-enabled ASP.NET pages, you'll see just how powerful both this object and ADO.NET are.

Migrating…

ADO.NET from ADO

Though much of ADO.NET is similar to ADO, a few things have changed. Most notably, the move from Recordset to Dataset objects, and the inclusion of XML data representation.

There are a lot of similarities between the Recordset and DataSet objects, but there are several things to be aware of. First, a Recordset was a simple representation of a table—it did not contain information on relationships, constraints, keys, and so on. A DataSet, however, does contain this information, as well as being able to contain more than one table of data at a time. This makes it much more functional than the Recordset.

Secondly, a DataSet is a completely separate entity from the database. You can even fill it manually without using a data source. This disconnected data provides a large performance boost over the connected data in a Recordset by not requiring extensive locks and active connections on data.

Finally, a DataSet represents its data internally with XML. Thus, you can easily retrieve data from a database with a DataSet, and then write it directly to an XML file. Or, conversely, you can load an XML file into a DataSet, and then insert it into a database. The Recordset object had no such capability.

The System.Data namespace also provides objects to interact with connected data sources, such as streams. These objects are usually more efficient than the disconnected data objects such as the DataSet, because they don't have to represent a complete database with keys, constraints, and other objects. However, due to that limited representation, they are also limited in functionality.

There are a few Web controls that are often associated with ADO.NET: the Repeater, DataList, and DataGrid controls. Though these controls are not part of the System.Data namespace, they are often associated with ADO.NET because of the way they interact with data sources. See the "System.Web.UI Namespace Set" section earlier in the chapter for more information.

Finally, the System.Data object also provides limited functionality to interact with XML data sources. You can load XML data and write it to a database, and vice versa. However, if you want to examine XML data in more depth, you should use the objects in the System.Xml namespace, which we'll discuss next.

Processing XML Files Using the System.XML Namespace

The System.Xml namespace provides all of the methods to process XML files—creating, parsing, transforming, searching, and so on. XML is a large part of ASP.NET (and ADO.NET, as discussed in the previous section), so you'll spend quite a bit of time with it later in the book.

Supplied Functionality

XML files are essentially pure text databases. Using a system of tags (like HTML), you can declare any type of data you'd like. For example, the following code shows a simple book database:

<?xml version=1.0?>

<book>

<title>To Kill A Mockingbird</title>

<author>Harper Lee</author>

</book>

</library>

You could easily insert this data into a database such as Microsoft SQL Server, but then you'd lose the readability and portability of the data. Thus, XML is designed to make any type of data universally available.

The XmlTextReader and XmlTextWriter objects are two of the most used objects in System.Xml because they provide lightweight and easy access to the data in XML files. You can navigate through an XML file with these objects just as you would a DataSet in ADO.NET. There are also objects that represent each part of an XML file, such as an XmlNode and XmlElement.

Also of interest are the System.Xml.Schema, System.Xml.Serialization, System.Xml.XPath, and System.Xml.Xsl sub-namespaces. These groups of objects provide additional functionality that will be very useful when dealing with XML data.

Summary

Microsoft.VisualBasic is a Microsoft specific namespace that provides access to the VB.NET compiler and code generator. You probably won't spend much time in this namespace unless you're interested in the inner workings of VB.NET.

The System namespace provides all of the foundations for the other namespaces, including the various data types and the Array. You'll be using the objects in this namespace quite a bit, and often without even realizing it.

System.Collections provides the base classes for the other collection objects in the .NET Framework, as well as a few useful regular classes, such as the HashTable and BitArray. You cannot use all of the base classes directly—they must be inherited from a custom class, or you can use one of the many existing classes that already inherit from them.

System.Web is a very important namespace for ASP.NET. It contains all of the functionality required to communicate between client and server; in essence, it is the heart of ASP.NET. The HttpRequest and HttpResponse objects enable you to examine data returned from a client (such as data from a form) and send information back to the client (for example, by using Response.Write). You can access the HttpServerUtility object through the Server object variable, and it provides additional functionality that helps when dealing with Internet communications.

Under the System.Web namespace are two very important sub-namespaces: System.Web.UI.HtmlControls and System.Web.UI.WebControls. These two namespaces provide all of the objects you'll use to display user interfaces to the client browser. Without these, you could not interact properly with users, if at all.

System.Data is essentially ADO.NET. In this namespace you'll find all of the tools you'll need to communicate with any type of data that ADO.NET can access. These classes can even interact with XML.

Finally, System.Xml enables you to handle and manipulate XML data. Note that System.Xml and System.Data are highly intertwined; you can use each namespace's classes to read and write each type of data, so the choice of which to use is often up to you.

You will be working with these namespaces throughout this book. For deeper information about these namespaces, the .NET Framework Documentation is an excellent resource.

Solutions Fast Track

Reviewing the Function of Namespaces

· Namespaces are logical collections of objects. A namespace is usually contained in a file called an assembly. These files outwardly look just like dynamically linked libraries (DLLs), and even end in the .dll extension.

· The main difference between .NET and non-.NET DLLs is that .NET DLLs are not compiled into machine language. Rather, they are compiled into the Microsoft Intermediate Language (MSIL), which is understood by the Common Language Runtime (CLR).

· To use a namespace in an ASP.NET page, you must use the Import directive. Unlike in classic ASP, ASP.NET pages are compiled before they are run. You build ASP.NET pages using a compiled language, such as VB.NET or C#.

Using the Microsoft.VisualBasic Namespace

· The Microsoft.VisualBasic namespace provides access to the VB.NET runtime.

· It enables you to access the compiler and code generator.

Understanding the Root Namespace: System

· The System namespace contains the foundation for the .NET Framework.

· It contains classes and structures representing the primitive data types (Integers, Strings, and so on).

· It also contains the very useful Array class.

Grouping Objects and Data Types with the System.Collections Namespace

· The System.Collections namespace provides the base classes for all other collection objects in the .NET Framework.

· It contains the HashTable object, which you may notice quite often in ASP.NET.

Enabling Client/Browser Communication with the System.Web Namespace

· The System.Web namespace is the foundation for all ASP.NET pages.

· It contains the System.Web.UI.WebControls and System.Web.UI.HtmlControls sub-namespaces, which provide the objects used to build UIs.

· It also contains the System.Web.Services namespace, which encapsulates the functionality needed to create and consume Web services.

Working with Data Sources Using the System.Data Namespace

· The classes in System.Data make up ADO.NET.

· It uses XML to represent data internally, enabling you to use XML files just as if they were a traditional data source.

Processing XML Files Using the System.XML Namespace

· The System.XML namespace provides access to XML files just as ADO.NET does with databases.

· XmlTextReader and XmlTextWriter objects allow for easy, lightweight manipulation of XML data.

· It provides tight integration with the objects in System.Data (ADO.NET).

Frequently Asked Questions

Q: Where are the namespaces located? How do I find them?

A: All of the .NET namespaces are located in assemblies (previously known as dynamically linked libraries, or DLLs). For example, System is located in the file System.dll. Note, however, that namespace names do not always represent the DLL files they are located in. For example, System.Web.UI is located in System.Web.dll, not in System.Web.UI.dll.

Q: What namespaces are automatically imported into ASP.NET pages?

A: System, System.Collections, System.IO, System.Web, System.Web.UI, System.Web.UI.HtmlControls, and System.Web.UI.WebControls all are imported implicitly by ASP.NET; you do not need to make explicit references to these.

Q: Do I have to import namespaces not included in the previous list?

A: No, there is no requirement to import additional namespaces. If you like, you can just reference an object not imported by default by its full namespace name. For example, if you don't import the System.Drawing namespace, you could use the following line in your code:

Dim objColor as System.Drawing.ColorConverter

Had you imported the System.Drawing namespace, you could simply use the following:

Dim objColor as ColorConverter

Q: Does importing namespaces add overhead to my applications?

A: Simply importing namespaces does not add overhead. The objects within the namespace are loaded only if they are needed, so you could import every namespace in the .NET Framework and notice no performance hit.

Q: Is there a way to view an assembly's methods and objects without programming or using the System.Reflection objects?

A: Absolutely! The Intermediate Language Disassembler enables you to view the technical details of any .NET assembly. You can run it from the command prompt with the command ildasm.exe. You can also use the object browser in Visual Studio .NET, which provides a more user-friendly listing of the objects and their methods/properties. Both of these methods are excellent tools for examining namespaces that you are curious about.

Q: How can I deploy custom namespaces?

A: Thanks to the .NET Framework, deploying namespaces and applications is very easy: all that is required is to copy the files to the target computer. There is no need to install or register assemblies or applications because the Common Language Runtime handles everything for you. There is one requirement, however, if you want the CLR to make custom assemblies automatically available to your applications: Place them in a \bin directory in your application folder. Assemblies in this folder are automatically loaded by the .NET runtime, though you can manually load assemblies that are not in this directory. See the .NET Framework Documentation for more details.