The Next Layer – .NET Framework Base Classes - Page 9

The next layer down in the framework provides the services and object models for data, input/output, security, and so forth. The next generation of ADO, called ADO.NET, resides here (though there will also be an updated version of regular ADO in .NET to provide compatibility for older code). Also included is the core functionality that lets you work with XML, including the parsers and XSL transformer.

Much of the functionality that a programmer might think of as being part of a language has been moved to the framework classes. For example, the Visual Basic keyword Sqr for extracting a square root is no longer available in .NET. It has been replaced by the System.Math.Sqrt method in the framework classes.

It's important to emphasize that all languages based on the .NET framework have these framework classes available. That means that COBOL, for example, can use the same function mentioned above for getting a square root. This makes such base functionality widely available and highly consistent across languages. All calls to Sqrt look essentially the same (allowing for syntactical differences among languages) and access the same underlying code.

As a side note, a programming shop can create their own classes for core functionality, such as globally available, pre- compiled functions. This custom functionality can then be referenced in code in the same way as built-in .NET functionality.

Much of the functionality in the base framework classes resides in a vast namespace called System. The System.Math.Sqrt method was mentioned above. Here are just a few other examples of the subsections of the System namespace, which actually contains dozens of such subcategories:

Namespace	What it contains	Example Classes
System.Data	Classes and types related to basic database management	DataSet, DataTable, DataColumn, SQLConnection, ADOConnection
System.Diagnostics	Classes to debug an application and to trace the execution of code	Debug, Trace
System.IO	Types which allow reading and writing to files and other data streams	File, FileStream, Path, StreamReader, StreamWriter
System.Math	Members to calculate common mathematical quantities, such as trigonometric and logarithmic functions	Sqrt (square root), Cos (cosine), Log (logarithm), Min (minimum)
System.Reflection	Capability to inspect metadata	Assembly, Module
System.Security	Types which enable security capabilities	Cryptography, Permissions, Policy

The list above merely begins to hint at the capabilities in the System namespace. Chapter 6 will examine the System namespace and other framework classes in more detail, and you can find a full list of .NET namespaces in Appendix A.

User and Program Interfaces

At the top layer, .NET provides three ways to render and manage user interfaces (Windows Forms, Web Forms, and Console Applications), and one way to handle interfaces with remote components (Web Services).

User Interfaces

Windows Forms

Windows Forms (which, as previously mentioned, are often just called WinForms) are a more advanced and integrated way to create standard Win32 desktop applications. WinForms are descended from the Windows Foundation Classes (WFC) originally created for J++, so this technology has been under development for a while.

All languages that work on the .NET Framework, including new versions of Visual Studio languages, will use the WinForms engine instead of whatever they are using now (MFC or direct Win32API calls in the case of C++, the VB Forms Engine in the case of Visual Basic). This provides a rich, unified set of controls and drawing functions for all languages, as well as a standard API for underlying Windows services for graphics and drawing. It effectively replaces the Windows graphical API, wrapping it in such a way that the developer normally has no need to go directly to the Windows API for any graphical or screen functions.

WinForms are actually part of the framework classes in the System.Winforms namespace, which makes them available to all languages that are based on the .NET framework. Since WinForms duplicate the functionality of the VB forms engine, they give every single .NET language the capability of doing forms just like Visual Basic. The drag-and-drop designer for WinForms (which is in Visual Studio.NET) can be used to create forms visually for use with any .NET language.

Chapter 9 will look at WinForms in more detail and note significant changes in WinForms versus older Visual Basic forms.

Changing the Tradeoffs for Client Applications Versus Browser-based Applications

In the Windows DNA world, many internal corporate applications are made browser-based simply because of the cost of installing and maintaining a client application on hundreds or thousands of workstations. WinForms and the .NET framework have the potential to change the economics of these decisions. A WinForms-based application will be much easier to install and update than an equivalent Visual Basic client application today. With a simple XCOPY deployment and no registration issues, installation and updating become much easier.

This means that applications that need a rich user interface for a large number of users are more practical under .NET than under Windows DNA. It may not be necessary to resort to browser-based applications just to save installation and deployment costs, thus extending the life of desktop-based applications.

Namespaces - Page 8
Introducing .NET
Web Forms - Page 10