From the Publisher

What is this book about?

.NET is designed to provide a new environment within which you can develop almost any application to run on Windows (and possibly in the future on other platforms). Visual Basic .NET (VB.NET) is likely to be a very popular development tool for use with this framework. VB.NET is a .NET compliant language and, as such, has (except for legacy reasons) almost identical technical functionality as the new C# language and Managed Extensions for C++. Using VB.NET, you can develop a dynamic Web page, a component of a distributed application, a database access component, or a classic Windows desktop application.

In order to incorporate Visual Basic into the .NET Framework, a number of new features have been added to it. In fact, the changes are so extensive that VB.NET should be viewed as a new language rather than simply as Visual Basic 7. However, these changes were necessary to give developers the features that they have been asking for: true object orientated programming, easier deployment, better interoperability, and a cohesive environment in which to develop applications.

What does this book cover?

In this book, we cover VB.NET virtually from start to finish: We begin by looking at the .NET Framework, and end by looking at best practices for deploying .NET applications. In between, we look at everything from database access to integration with other technologies such as XML, along with investigating the new features in detail. You will see that VB.NET has emerged as a powerful yet easy to use language that will allow you to target the Internet just as easily as the desktop.

This book explains theunderlying philosophy and design of the .NET Framework and Common Language Runtime (CLR) and explains the differences between Visual Basic 6 and Visual Basic .NET.

You will learn how to

• Develop applications and components using Visual Studio .NET
• Effectively apply inheritance and interfaces when designing objects and components
• Organize your code using namespaces
• Handle errors using the Try...Catch...Finally structure
• Access data using ADO.NET and bind controls to the underlying data sources
• Create Windows applications and custom Windows controls
• Interoperate with COM and ActiveX components
• Create transactional and queuing components
• Use .NET Remoting to send serialized objects between clients and servers
• Create Windows Services
• Use VB.NET to access information on the Web
• Create and consume Web Services
• Secure your applications and code using the tools provided in the .NET Framework SDK
• Arrange your applications and libraries in assemblies and deploy them using Visual Studio .NET

Who is this book for?

This book is aimed at experienced Visual Basic developers who want to make the transition to VB.NET.

What do you need to use this book?

Although it is possible to create VB.NET applications using the command lines tools contained in the .NET Framework SDK, you will need Visual Studio .NET (Professional or higher), which includes the .NET Framework SDK, to use this book to the full.

Here are some additional notes on what you may need:

• Some chapters make use of SQL Server 2000. However, you can also run the example code using MSDE (Microsoft Data Engine), which ships with Visual Studio .NET.
• Several chapters make use of Internet Information Services (IIS). IIS ships with Windows 2000 Server, Windows 2000 Professional, and Windows XP, although it is not installed by default.
• Chapter 18 makes use of MSMQ to work with queued transactions. MSMQ ships with Windows 2000 Server, Windows 2000 Professional, and Windows XP, although it is not installed by default.

Product Details

• Table of Contents
• Read a Sample Chapter

Table of Contents

Read a Sample Chapter

Professional VB.NET

John Wiley & Sons

Chapter One

Microsoft began its Internet development efforts in 1995. Prior to this, Microsoft's focus had, for several years, been on moving desktop and server operating systems to 32-bit, GUI-based technologies, but once Microsoft realized the importance of the Internet, it made a dramatic shift. The company became focused on integrating its Windows platform with the Internet and it succeeded in making Windows a serious platform for the development of Internet applications.

However, it had been necessary for Microsoft to make some compromises in order to quickly produce Internet-based tools and technologies. The most glaring example was Active Server Pages (ASP). While ASP was simple in concept and easily accessible to new developers, it did not encourage structured or object-oriented development. Creating user interfaces with interpreted script and limited visual elements was a real step back from the form-based user interfaces of Visual Basic (VB). Many applications were written with a vast amount of interpreted script, which lead to problems of debugging and maintenance.

Visual Basic (and other languages) has continued to be used in Internet applications on Microsoft platforms, but mostly to create components that were accessed in ASP. Before Microsoft .NET, Microsoft tools were lacking in their integration and ease-of-use for web development. The few attempts that were made to place a web interface on traditional languages, such as WebClasses in VB, were compromises that never gained widespread acceptance. The result was that developing a large Internet application required the use of a large number of loosely integrated tools and technologies.

Microsoft .NET is the first software development platform to be designed from the ground up with the Internet in mind - although .NET is not exclusively for Internet development; rather it provides a consistent programming model that can be used for many types of applications. However, when an application needs Internet capabilities, access to those capabilities is almost transparent, unlike tools currently used for Internet-enabled applications.

To understand what the importance of .NET is, it's helpful to understand how current tools such as COM limit us in a development model based on the Internet. In this chapter, we'll look at what's wrong with COM and the DNA architectural model, and then examine how .NET corrects the drawbacks in these technologies.

Although we'll discuss the drawbacks of current tools in the context of the Microsoft platform, almost all apply in some form to all the platforms that are currently available for Internet development. Moreover, many of these other platforms have unique drawbacks of their own.

The DNA Programming Model

In the late 1990s, Microsoft attempted to bring some order to Internet development with the concept of Windows DNA applications. DNA consists of a standard three-tier development based on COM, with ASP (as well as Win32 clients) in the presentation layer, business objects in a middle layer, and a relational data store and engine in the bottom layer. The following diagram shows a generic Windows DNA application:

Presentation Tier

In Windows DNA, there are two types of user interfaces - Win32 clients and browser-based clients.

Win32 clients are most often produced with a visual development tool such as Visual Basic. They are simple to create, and offer a rich user interface. The drawback of such software is that it is difficult to deploy and maintain - it must be installed on every client and every installation must be altered whenever an upgrade to the software is made. In addition to these logistical difficulties, DLL conflicts frequently occur on the client because of variations in the version of the operating system and other software installed on the client. This is known as DLL Hell, which we'll discuss later on.

Browser-based clients are far easier to deploy than Win32 clients as the client only needs a compatible browser and a network (Internet or intranet) connection. However browser-based clients are often more difficult to create than Win32 clients, and offer a more limited user interface that has fewer controls and permits only limited control over the layout of the screen and the handling of screen events.

There are some in-between options. If clients are restricted to certain browsers, Dynamic HTML (DHTML) can be used to add functionality to the interface. If clients are further restricted to Internet Explorer (IE), ActiveX controls can be used to create an interface that is close to that available in a Win32 client. However, ActiveX controls have deployment issues of their own. VB can be used to create ActiveX controls, but then deploying the controls requires lots of supporting VB DLLs to be present on the client. Consequently, ActiveX controls are typically written in C++ to make the installation as lightweight as possible, but this adds to development time and requires a higher level of development expertise.

One important factor that is often overlooked in the DNA model is that there may be a need to implement both Win32-based and Internet-based user interfaces. Alternatively, there may be a need to have different types of user interface, perhaps one for novice or occasional users, and one for advanced users. This is practical only if the design of the system keeps the user interface layer as thin as possible. Normally, it should only contain logic that manages the user interface and performs basic validation of user data. (Such validation of data in the client layer is important as it minimizes round trips to the server.)

Middle Tier

The middle tier in a DNA application should encapsulate as much of the business logic processing as possible. Apart from those rules that are needed to validate data on the client, all the business rules should be in the middle layer.

The middle tier is often broken down into sub-tiers. One tier may handle the interface to the client, another tier the business rules, and another tier the interface to the data repositories.

Visual Basic is the language most commonly used to write middle-tier components. This is a more sophisticated type of development than for forms-based Visual Basic programs; it requires a greater level of expertise in COM and object-oriented programming. Understanding COM is important in constructing a middle tier because the components in this layer must work together, which means that all the components must be versioned properly so that they can understand each other's interfaces. It's also important to create components that scale well, which often means developing components that are implemented using Microsoft Transaction Server (MTS) or COM+ Services. Such components typically use stateless designs, which can look very different from the stateful designs commonly used in client-based components.

Components in the middle tier may use a variety of protocols and components to communicate data to the data tier. The diagram shows examples such as HTTP, ADO (ActiveX Data Objects), ADSI (Active Directory Service Interfaces), and CDO (Collaboration Data Objects), but that list is by no means exhaustive.

Data Tier

Most business applications must store information for long-term use. The nature of the storage mechanism varies with the installation but a relational database management system (RDBMS) is often required, with the most common options being Microsoft SQL Server and Oracle. However, if the information is based around documents and messages, a messaging data store such as Exchange may be required, and many installations will depend on legacy mainframe systems.

Besides holding the data, the data tier may also contain logic that processes, retrieves, and validates data. Stored procedures, written in some variation of SQL (Structured Query Language), can be used with RDBMS databases to do this.

Issues with the DNA Model

The concept behind DNA is sound, but actually getting it to work well is overly complicated. A DNA application will often require:

Visual Basic code in forms, as well as in components on both the client and the server

ASP scripting code as well as client-side scripting

HTML, DHTML, CSS (Cascading Style Sheets)

XML, XSL

C++ in ActiveX components Stored procedures (Transact-SQL in SQL Server or PL-SQL in Oracle)

With so many options, it's all too easy to make inappropriate design decisions, such as putting logic on the client that belongs on the server, or creating VBScript for formatting when CSS would work better. Designing and constructing a complex DNA-based application requires a high level of expertise in a number of different technologies.

The Limitations of COM

While COM is a viable platform for enterprise-level Internet applications, it does have some serious limitations. Let's cover some of the major ones.

DLL Hell

COM-based applications are subject to major deployment and configuration issues. Small changes in COM interfaces can render entire applications inoperable. This problem, in which small problems cascade through an entire component-based tier is often referred to as DLL Hell - experienced COM developers will attest to the appropriateness of the term. Getting a large set of DLLs to a compatible state of versioning requires skill and a well-controlled deployment process.

While DLL Hell is most common in the middle tier, there are also deployment issues in the client tier that are caused by COM. Any forms-based interface will depend on COM components in order to function. Some of these components are from the tool used to create the interface (such as Visual Basic); others may be custom-written DLLs. All will need to be installed on the client.

The class IDs (which are GUID-based identifiers) of all the COM-based components must be placed in the local client's Windows Registry. Complex installation programs typically do this. Getting all the necessary components registered and properly versioned on the client is a variant of DLL Hell, and makes deploying client applications to large numbers of desktop machines an expensive process. This has driven many application designers to use browser-based interfaces whenever possible in order to avoid such deployment costs, even though the browser user interface is not as flexible.

Lack of Interoperability with Other Platforms

COM works well on pure Microsoft platforms but it doesn't provide the ability to activate or interoperate with components on other platforms such as UNIX. For enterprise-level applications, this is a significant shortcoming as large organizations often have a variety of operating platforms, and require interoperability between them.

Lack of Built-In Inheritance

One of the most important ways in which functionality can be reused is for a software component to be inherited by another component, and then extended with new functionality. (Chapter 6 covers this issue in detail.) Inheritance is crucial in developing complex application frameworks, but COM does not support inheritance natively.

Inheritance has been possible on Microsoft platforms at the source language level, using languages such as C++ and Delphi. However, since inheritance is not built into the basic structure of COM, many languages (such as VB6) don't support it, and there was no capability on Microsoft platforms before .NET to allow languages to inherit from components written in another language.

Limitations of VB6 for DNA Application Development

Visual Basic 6 is easily the most popular language for developing applications with the DNA model. It is used in two major roles: forms-based VB clients and COM components (either on the client or the server). There are other options, of course, including C++, J++, and various third-party languages such as Delphi and Perl, but the number of VB developers outnumbers them all put together.

However, although it's popular, VB6 isn't without its limitations, which include:

No capability for multithreading - which implies, for example, that VB6 can't be used to write an NT-type service. There are also situations in which the apartment threading used by components created in VB6 limits performance.

A lack of implementation inheritance and other object-oriented features - this makes VB6 unsuitable for the development of object-based frameworks.

Poor error-handling ability - VB6's archaic error handling becomes especially annoying in a multi-tier environment. It's difficult in VB6 to track and pass errors through a stack of component interfaces.

Poor integration with other languages such as C++ - VB6's implementation of COM, although easy to use, causes problems with such integration. Class parameters (object interfaces) in VB6 are "variant compliant", forcing C++ developers who want to integrate with VB to convert parameters to less appropriate types. These varying data structures and interface conventions must be resolved before components in VB can be integrated into a multiple language project. Besides requiring extra code, these conversions may also result in a performance hit.

No effective user interface for Internet-based applications - perhaps the biggest drawback to using VB6 became apparent when developing for the Internet. While VB6 forms for a Win32 client were state-of-the-art, for applications with a browser interface VB6 was mostly relegated to use in components.

Microsoft tried to address this last problem in VB6 with WebClasses and DHTML Pages but neither caught on:

WebClasses offered an obscure programming model, and limited control over visual layout.

DHTML Pages in VB6 had to send a (usually large) DLL to the client, and so needed a high-bandwidth connection to be practical. This limited their use mostly to intranet applications. DHTML Pages were also restricted to Internet Explorer.

Limitations of DNA Internet Development

There are a few additional areas in which previous Microsoft tools and technologies fell short of the ideal for Internet application development.

Different Programming Models

With DNA-based software development, creating software that is accessed by a user locally is done very differently from development for the Internet. The starkest example of this is the use of VB forms for client-server user interfaces versus the use of ASP for Internet user interfaces. Even though both situations involve designing and implementing GUI-based user interfaces, the tools and programming techniques used are quite different.

Continues...

---

Excerpted from Professional VB.NET by Fred Barwell Richard Case Bill Forgey Billy Hollis Tim McCarthy Jonathan Pinnock Richard Blair Jonathan Crossland Whitney Hankison Rockford Lhotka Jan Narkiewicz Rama Ramachandran Matthew Reynolds John Roth Bill Sheldon Bill Sempf Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---