Introducing .NET

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.

Web Forms

A part of ASP.NET, Web Forms are a forms engine. They provide a web browser-based user interface. A user interface can also be rendered with the updated version of Active Server Pages, but Web Forms represents the next generation of web interface development, including drag-and-drop development.

Divorcing layout from logic, Web Forms consist of two parts - a template, which contains HTML-based layout information for all user interface elements, and a component, which contains all logic to be hooked to the UI. It's as if a standard Visual Basic form were 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 operated "behind" the controls, with events in the controls activating event routines in the code.

To make this new UI concept work, Web Forms have lots of built-in intelligence. Controls on Web Forms run on the server but make their presence known on the client. This takes lots of coordination and behind-the-scenes activity. However, the end result is web interfaces that can look and behave very much like Win32 interfaces today, and the ability to produce such interfaces with a drag-and-drop design tool. These web interfaces can also have the intelligence to deal with different browsers, optimizing their output for each particular browser. Supported browsers cover a broad range. At the top end are advanced modern versions like Internet Explorer 5.5, which support DHTML. At the other end are simpler, less capable browsers on hardware such as wireless palmtop devices. Web Forms will render themselves appropriately on all of these.

As with WinForms, Web Forms will be available to all languages. The component handling logic for a form can be coded in any language that supports .NET. This brings complete and flexible web interface capability to a wide variety of languages.

Server controls

Visual Basic developers are familiar with the idea of controls. They are the reusable user interface elements used to construct a form. The equivalent in a Web Form is called server-side controls.

Server-side controls essentially create a proxy on the server for a user interface element that is on a Web Form or Active Server Page. The server-side control communicates with local logic as necessary, and then intelligently renders its own UI as HTML as necessary in any pages that are sent out containing the control. It also handles its own HTML responses, and incorporates the returned data.

Server-side controls need significant intelligence to render HTML for different levels of browsers, and to coordinate events with the client on which the page is running. A wide variety of controls are expected to ship with Visual Studio.NET, bringing web-based interfaces much closer to Win32 interfaces. Third parties are expected to add even more options for server-side controls.

One of the most important and amazing features of server-side controls is that they manage their own state. In ASP.NET, it is no longer necessary to write a lot of tedious code to reload state information into HTML controls every time a page is refreshed. Web Forms handle state by sending a tokenised (compressed) version of the state information to the client browser each time a page is sent. The page then posts that state information back to the server when changing the page. The server controls grab this information, use or process it as necessary, and then send it out again with the next rendering of the page.

Console Applications

Though Microsoft doesn't emphasize the ability to write character-based applications, the .NET Framework does include an interface for such console apps. Batch processes, for example, can now have components integrated into them that are written to a console interface. (The part of the .NET Framework which implements the console interface is not shown in the .NET Framework diagram earlier in the chapter.)

As with WinForms 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 GUI interface. Visual Basic.NET can be used for true console applications.

Program Interfaces

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, which used lots of base functionality from other, system-level 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 represents 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, (diagrammed at the top level of the .NET Framework), which handles all web interfaces. It allows programs to talk to each other directly over the web, using SOAP. This capability requires very little work on the part of the developer. All that is needed is to indicate that a member should be included in the Web Services interface, and the .NET Framework takes care of the rest. This has the capacity to dramatically change the architecture of web applications, allowing services running all over the web to be integrated into one application.

It is hard to over-emphasize the potential importance of Web Services. Consider, for example, the potential for Web Services to replace packaged software. A commercial software company could produce a Web Service that, for instance, calculates sales tax for every jurisdiction in the nation. A subscription to that web service could be sold to any company needing to calculate sales tax. The customer company then has no need to deploy the sales tax calculator because is it just called on the web. The company producing the sales tax calculator can dynamically update it to include new rates and rules for various jurisdictions, and their customers using the Web Service don't have to do anything to get these updates.

There are endless other possibilities. Stock tickers, weather information, current financial rates, shipping status, and a host of other types of information could be exposed as a Web Service, ready for integration into any application that needs it.

Chapter 8 contains a detailed discussion of Web Services.

XML as the .NET "Meta-language"

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 for better remote manipulation of data, is heavily dependent on XML for 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 data store by ADO.NET when remote manipulation
is finished.

With XML as an "entry point" into so many areas of .NET, future 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.

How COM/COM+ Fits In

The internals of the .NET Framework do not depend on COM to tie themselves together. Components that are written purely for .NET use the interface conventions of .NET, which are executed and enforced by the CLR.

This has been misinterpreted in some quarters as the immediate death of COM and COM+. It reminds me of a great historical quote. When Mark Twain's obituary was accidentally published, he talked to journalists on his porch, and said "The rumors of my death are greatly exaggerated." So it is with COM/COM+.

The .NET Framework makes it transparent to deal with a COM/COM+ component as if it were a .NET component. Interface translation is automatic. And any .NET Framework component can also be treated as a COM component by traditional COM-based software.

Microsoft knew that the .NET Framework must integrate with existing software. Most organizations have a tremendous investment in COM/COM+. There is no need whatsoever to replace that investment. In fact, a lot of the existing software that needs to be used in conjunction with .NET is, in fact, in Microsoft packages such as SQL Server and Exchange. As discussed at the beginning of the chapter, the .NET Enterprise Servers are COM-based, and will be an important part of .NET development projects for quite a while to come.

Will COM and COM+ eventually die off as .NET comes to dominate? Perhaps. But it's not an issue any of us need be concerned with at present.