The Next Layer — The .NET Class Framework

The next layer up in the framework provides the services and object models for data, input/output, security, and so forth. It is called the .NET Class Framework, sometimes referred to as the .NET base classes. For example, the next generation of ADO, called ADO.NET, resides here. Some of the additional functionality in the .NET Class Framework is listed below. You might be wondering why .NET includes functionality that is, in many cases, duplication of existing class libraries. There are several good reasons:

The .NET Class Framework libraries are implemented in the .NET Framework, making them easier to integrate with .NET-developed programs.

The .NET Class Framework brings together most of the system class libraries needed into one location, which increases consistency and convenience.

The class libraries in the .NET Class Framework are much easier to extend than older class libraries, using the inheritance capabilities in .NET.

Having the libraries as part of the .NET Framework simplifies deployment of .NET applications. Once the .NET Framework is on a system, individual applications don’t need to install base class libraries for functions like data access.

What Is in the .NET Class Framework?
The .NET Class Framework contains literally thousands of classes and interfaces. Here are just some of the functions of various libraries in the .NET Class Framework:

Data access and manipulation

Creation and management of threads of execution

Interfaces from .NET to the outside world—Windows Forms, Web Forms, Web Services, and console applications

Definition, management, and enforcement of application security

Encryption, disk file I/O, network I/O, serialization of objects, and other system-level functions

Application configuration

Working with directory services, event logs, performance counters, message queues, and timers

Sending and receiving data with a variety of network protocols

Accessing metadata information stored in assemblies

Much of the functionality that a programmer might think of as being part of a language has been moved to the base classes. For example, the old VB 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. Here are examples in VB.NET and C#: ‘ Example using Sqrt in Visual Basic .NET Dim dblNumber As Double = 200 Dim dblSquareRoot As Double dblSquareRoot = System.Math.Sqrt(dblNumber) Label1.Text = dblSquareRoot.ToString ‘ Same example in C# Double dblNumber = 200; Double dblSquareRoot = System.Math.Sqrt(dblNumber); dblSquareRoot = System.Math.Sqrt(dblNumber); label1.Text = dblSquareRoot.ToString;

What Is Microsoft .NET?
Notice that the line using the Sqrt() function is exactly the same in both languages. As a side note, a programming shop can create its own classes for core functionality, such as globally available, already compiled functions. This custom functionality can then be referenced in code 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 just mentioned. The System namespace contains dozens of such subcategories. The table below lists a few of the important ones, many of which you will be using in various parts of this book.

User and Program Interfaces
At the top layer, .NET provides three ways to render and manage user interfaces:

Windows Forms

Web Forms

Console applications Namespace

What It Contains Example Classes and Subnamespaces System.Collections Creation and management of Arraylist, various types of collections Hashtable, SortedList System.Data Classes and types related to DataSet, basic database management DataTable, (see Chapter 11 for details) DataColumn, System.Diagnostics Classes to debug an application Debug, Trace and to trace the execution of code System.IO Types that allow reading and File, FileStream, Path, writing to and from files and StreamReader, StreamWriter other data streams System.Math Members to calculate common Sqrt (square root), Cos (cosine), mathematical quantities, such as Log (logarithm), Min (minimum) trigonometric and logarithmic functions System.Reflection Capability to inspect metadata Assembly, Module System.Security Types that enable security Cryptography, Permissions, capabilities (see Chapter 24 Policy for details)

Windows Forms
Windows Forms is a more advanced and integrated way to do standard Win32 screens. All languages that work on the .NET Framework, including new versions of Visual Studio languages, use the Windows Forms engine, which duplicates the functionality of the old VB forms engine. It 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. In Chapter 14, you will look at Windows Forms in more detail and note significant changes in Windows Forms versus older VB forms. Chapter 15 continues discussing advanced Windows Forms capabilities such as creation of Windows Forms visual controls.

Client Applications versus Browser-Based Applications
Before .NET, many internal corporate applications were made browser-based simply because of the cost of installing and maintaining a client application on hundreds or thousands of workstations. Windows Forms and the .NET Framework change the economics of these decisions. AWindows Forms application is much easier to install and update than an equivalent VB6 desktop application. With a simple XCOPY deployment and no registration issues, installation and updating become much easier. Internet deployment via ClickOnce also makes applications more available across a wide geographic area, with automatic updating of changed modules on the client. That means that “smart client” applications with a rich user interface are more practical under .NET, even for a large number of users. It may not be necessary to resort to browser-based applications just to save on installation and deployment costs. As a consequence, you should not dismiss Windows Forms applications as merely replacements for earlier VB6 desktop applications. Instead, you should examine applications in .NET and explicitly decide what kind of interface makes sense in a given case. In some cases, applications that you might have assumed should be browser-based simply because of a large number of users and wide geographic deployment instead can be smart-client-based, which can improve usability, security, and productivity.

Web Forms
The part of .NET that handles communications with the Internet is called ASP.NET. It includes a forms engine, called Web Forms, which can be used to create browser-based user interfaces. Divorcing layout from logic, Web Forms consist of two parts:

A template, which contains HTML-based layout information for all user interface elements

A component, which contains all logic to be hooked to the user interface

It is as if a standard Visual Basic form was split into two parts, one containing information on controls and their properties and layout, and the other containing the code. Just as in Visual Basic, the code operates “behind” the controls, with events in the controls activating event routines in the code. As with Windows Forms, Web Forms will be available to all languages. The component handling logic for a form can be in any language that supports .NET. This brings complete, flexible Web interface capability to a wide variety of languages. Chapters 16 and 17 go into detail on Web Forms and the controls that are used on them. If you have used ASP.NET in previous versions of .NET, you should know that ASP.NET 2.0 has dramatic improvements. With even more built-in functionality for common browser tasks, applications can be written with far less code in ASP.NET 2.0 as compared to earlier versions. Capabilities such as user authentication can now be done with prebuilt ASP.NET components, so you no longer have to write such components yourself.

Console Applications
Although Microsoft doesn’t emphasize the ability to write character-based applications, the .NET Framework does include an interface for such console applications. Batch processes, for example, can now have components integrated into them that are written to a console interface. As with Windows Forms and Web Forms, this console interface is available for applications written in any .NET language. Writing character-based applications in previous versions of Visual Basic, for example, has always been a struggle, because it was completely oriented around a graphical user interface (GUI). VB.NET can be used for true console applications.

Web Services
Application development is moving into the next stage of decentralization. The oldest idea of an application is a piece of software that accesses basic operating system services, such as the file system and graphics system. Then we moved to applications that used lots of base functionality from other systemlevel applications, such as a database—this type of application added value by applying generic functionality to specific problems. The developer’s job was to focus on adding business value, not on building the foundation. Web Services represent the next step in this direction. In Web Services, software functionality becomes exposed as a service that doesn’t care what the consumer of the service is (unless there are security considerations). Web Services allow developers to build applications by combining local and remote resources for an overall integrated and distributed solution. In .NET, Web Services are implemented as part of ASP.NET (see Figure 1-1), which handles all Web interfaces. It allows programs to talk to each other directly over the Web, using the SOAP standard. This has the capacity to dramatically change the architecture of Web applications, allowing services running all over the Web to be integrated into a local application. Chapter 23 contains a detailed discussion of Web Services.

XML as the .NET Metalanguage
Much of the underlying integration of .NET is accomplished with XML. For example, Web Services depend completely on XML for interfacing with remote objects. Looking at metadata usually means looking at an XML version of it. ADO.NET, the successor to ADO, is heavily dependent on XML for the remote representation of data. Essentially, when ADO.NET creates what it calls a dataset (a more complex successor to a recordset), the data is converted to XML for manipulation by ADO.NET. Then, the changes to that XML are posted back to the datastore by ADO.NET when remote manipulation is finished. Chapter 12 discusses XML in .NET in more detail, and, as previously mentioned, Chapter 11 contains a discussion of ADO.NET. With XML as an “entry point” into so many areas of .NET, integration opportunities are multiplied. Using XML to expose interfaces to .NET functions allows developers to tie components and functions together in new, unexpected ways. XML can be the glue that ties pieces together in ways that were never anticipated, both to Microsoft and non-Microsoft platforms.

The Role of COM
When the .NET Framework was introduced, some uninformed journalists interpreted it as the death of COM. That is completely incorrect. COM is not going anywhere for a while. In fact, Windows will not boot without COM. .NET integrates very well with COM-based software. Any COM component can be treated as a .NET component by native .NET components. The .NET Framework wraps COM components and exposes an interface that .NET components can work with. This is absolutely essential to the quick acceptance of .NET because it makes .NET interoperable with a tremendous amount of older COM-based software. Going in the other direction, the .NET Framework can expose .NET components with a COM interface. This allows older COM components to use .NET-based components as if they were developed using COM. Chapter 20 discusses COM interoperability in more detail.

No Internal Use of COM
It is important, however, to understand that native .NET components do not interface using COM. The CLR implements a new way for components to interface, one that is not COM-based. Use of COM is only necessary when interfacing with COM components produced by non-.NET tools. Over a long span of time, the fact that .NET does not use COM internally may lead to the decline of COM, but for any immediate purposes, COM is definitely important.

Some Things Never Change . . .
Earlier, this chapter discussed the limitations of the pre-.NET programming models. However, those models have many aspects that still apply to .NET development. Tiered layers in software architecture, for example, were specifically developed to deal with the challenges in design and development of complex applications and are still appropriate. Many persistent design issues, such as the need to encapsulate business rules, or to provide for multiple user interface access points to a system, do not go away with .NET. Applications developed in the .NET Framework will still, in many cases, use a tiered architecture. However, the tiers will be a lot easier to produce in .NET. The presentation tier will benefit from the new interface technologies, especially Web Forms for Internet development. The middle tier will require far less COM-related headaches to develop and implement. And richer, more distributed middle tier designs will be possible by using Web Services. The architectural skills that experienced developers have learned in earlier models are definitely still important and valuable in the .NET world.

.NET Drives Changes in Visual Basic
This chapter previously covered the limitations of Visual Basic in earlier versions. To recap, they are:

No capability for multithreading

Lack of implementation inheritance and other object features

Poor error-handling ability

Poor integration with other languages such as C++

No effective user interface for Internet-based applications

Since VB.NET is built on top of the .NET Framework, all of these shortcomings have been eliminated. In fact, Visual Basic gets the most extensive changes of any existing language in the VS.NET suite. These changes pull Visual Basic in line with other languages in terms of datatypes, calling conventions, error handling, and, most importantly, object orientation. Chapters 4, 5, and 7 go into detail about objectoriented concepts in VB.NET, and Chapter 10 discusses error handling, which is known in .NET as “exception handling.”

How .NET Affects You
One of the reasons you are probably reading this book is that you want to know how VB.NET will affect you as an existing Visual Basic developer. Here are some of the most important implications.

A Spectrum of Programming Models
In previous Microsoft-based development tools, there were a couple of quantum leaps required to move from simple to complex. A developer could start simply with ASP pages and VBScript, but when those became cumbersome, it was a big leap to learn component-based, three-tier development in Visual Basic. And it was another quantum leap to become proficient in C++, ATL, and related technologies for system-level work. A key benefit of VB.NET and the .NET Framework is that there exists a more gradual transition in programming models from simple to full power. ASP.NET pages are far more structured than ASP pages, and code used in them is often identical to equivalent code used in a Windows Forms application. Internet development can now be done using real Visual Basic code instead of VBScript. Visual Basic itself becomes a tool with wider applicability, as it becomes easy to do a Web interface with Web Forms, and it also becomes possible to do advanced object-oriented designs. Even system-level capabilities, such as Windows Services can be done with VB.NET (see Chapter 25). Old reasons for using another language, such as lack of performance or flexibility, are mostly gone. Visual Basic will do almost anything that other .NET languages can do. This increases the range of applicability of Visual Basic. It can be used all the way from “scripts” (which are actually compiled on the fly) written with a text editor up through sophisticated component and Web programming in one of the most advanced development environments available.

Reducing Barriers to Internet Development
With older tools, programming for the Internet requires a completely different programming model than programming systems that will be run locally. The differences are most apparent in user interface construction, but that’s not the only area of difference. Objects constructed for access by ASP pages, for example, must support Variant parameters, but objects constructed for access by Visual Basic forms can have parameters of any datatype. Accessing databases over the Internet requires using technologies like RDS instead of the ADO connections that local programming typically uses. The .NET Framework erases many of these differences. Programming for the Internet and programming for local systems are much more alike in .NET than with today’s systems. Differences remain—Web Forms still have significant differences from Windows Forms, for example, but many other differences, such as the way data is handled, are much more unified under .NET. A big result of this similarity of programming models is to make Internet programming more practical and accessible. With functionality for the Internet designed in from the start, developers don’t have to know as much or do as much to produce Internet systems with the .NET Framework.

Libraries of Prewritten Functionality
The evolution of Windows development languages, including Visual Basic, has been in the direction of providing more and more built-in functionality so that developers can ignore the foundations and concentrate on solving business problems. The .NET Framework continues this trend. One particularly important implication is that the .NET Framework extends the trend of developers spending less time writing code and more time discovering how to do something with prewritten functionality. Mainframe COBOL programmers could learn everything they ever needed to know about COBOL in a year or two and very seldom need to consult reference materials after that. In contrast, today’s Visual Basic developers already spend a significant portion of their time digging through reference material to figure out how to do something that they may never do again. The sheer expanse of available functionality, plus the rapidly changing pace, makes it imperative for an effective developer to be a researcher also. .NET accelerates this trend, and will probably increase the ratio of research time to coding time for a typical developer.

Easier Deployment
A major design goal in Microsoft .NET is to simplify installation and configuration of software. With DLL hell mostly gone, and with installation of compiled modules a matter of a simple file copy, developers should be able to spend less time worrying about deployment of their applications, and more time concentrating on the functionality of their systems. The budget for the deployment technology needed by a typical application will be significantly smaller.

The Future of .NET
At the Professional Developer’s Conference (PDC) in Los Angeles in October of 2003, Microsoft gave the first public look at their next-generation operating system, code-named Longhorn. It was clear from even this early glimpse that .NET is at the heart of Microsoft’s operating system strategy going forward. However, the naming of what is now known as .NET is going to change. While Web Services and related technologies may still carry the .NET label going forward, the .NET Framework is called WinFX in Longhorn. This may cause some confusion in names going forward, but be assured that what you learn today about the .NET Framework and VB.NET will be important for years to come in the world of Microsoft applications.

Major Differences in .NET 2.0
If you are familiar with earlier versions of .NET, you will want to pay special attention to areas that have been significantly changed. Here is a list of some of the most important additions and changes, with the chapter you should check for more information: Feature Description Chapter(s) Edit and Allows you to make changes to code while you are running it 2 Continue in the integrated development environment (IDE) and have the changes take effect immediately. (This feature was available in VB6 and earlier, but was not available in Visual Basic 2002 or 2003.) Partial classes Allows code for a class to be split over multiple code modules. 4 Generics Allows generic collections to handle specific types, declared 8 when the collection is created. Data binding There are many new controls for data binding and new 15 designer support such as drag-and-drop of data fields onto Windows Forms. ClickOnce New deployment technology for deploying across the Internet, 19 with automatic updating. “My” classes Provides quick access to commonly used classes in the .NET 2 Framework. Nullable types Allows data types that can either hold a value or be null, 3 allowing .NET types to match up to database types more transparently. Operator Allows you to define operations between arbitrary types, such 5 overloading as the ability to define a “+” operation for two Account objects. IsNot keyword Simplifies If statements that check if an object is Nothing. 2 Using keyword Automates disposing of objects created in a section of code. 4 IDE Exception manager, code snippets with automatic fill-in, 2 improvements improved IntelliSense, and autocorrect are a few of the new capabilities of the IDE.

Summary
VB.NET is not like other versions of Visual Basic. It is built with completely different assumptions, on a new platform that is central to Microsoft’s entire product strategy. This chapter discussed the reasons Microsoft has created this platform and how challenges in earlier, pre-Internet technologies have been met by .NET. This chapter has also discussed in particular how this will affect VB developers. .NET presents many new challenges for developers but simultaneously provides them with greatly enhanced functionality. In particular, Visual Basic developers now have the ability to develop object-oriented and Web-based applications far more easily and cheaply. The next chapter takes a closer look at the VS.NET IDE, and discusses the basics of doing applications in VB.NET.

Click Here to Purchase this Book

Cite Systems

704.918.9959
4456 Central Ave
Charlotte, NC
http://www.citesys.com/services/email/comparison.aspx