Visual Basic .NET

I l @ ve RuBoard

I haven't really said much about Visual Basic yet. Everything I've said so far applies to all applications, regardless of what language they're implemented in. But since this book is about enterprise application development in Visual Basic .NET, I should spend a least a little time looking at the language itself.

Visual Basic has traditionally been about lowering the bar for developers and about making development more accessible to more people. Microsoft's vision for Visual Basic .NET has not really changed in this regard, but Microsoft has added a host of important features to the language and thrown out a lot of legacy deadweight. Still, it is important to understand Visual Basic .NET in its historical context.

Visual Basic Then and Now

In the past, I always said that you don't build large applications in Visual Basic, you build them around Visual Basic. This was true because the needs of enterprise or large-scale applications were at odds with Visual Basic ”mostly because of the lack of important object-oriented programming (OOP) features that would make large-scale development projects manageable. This often led to code bloat and odd designs that were difficult to maintain.

Classic Visual Basic was not without its benefits, however. Thanks to a development environment and COM-based architecture, you could create large, complex applications quickly. Visual Basic has always been known as a rapid application development (RAD) platform. One fairly common approach to developing applications was to implement them quickly in Visual Basic and then isolate the critical performance areas and replace the components with Visual C++ components . This type of development offered three distinct advantages:

• You could create a fully functional application relatively quickly.

• You had a reference implementation for the admittedly harder-to-build C++ components.

• Your test people could build tests based on the Visual Basic code right away, providing a great functional check against any replacement components.

The Limitations of COM

Visual Basic wasn't the only problem when it came to developing large applications, however. COM didn't always make things easy, either. COM has to be the most successful component architecture in the entire history of computing. It made its first appearance in 1993 and has become the dominant component architecture for the Windows platform. Visual Basic 6.0 is by far the best platform for creating COM components quickly and easily. But COM is not without its own problems:

• You cannot inherit from COM components. The only way to leverage existing components is to encapsulate and tack on the functionality you need. COM offers no inherent ability to extend COM components. This is a significant architectural limitation, although it obviously has not presented too great a limitation ” otherwise , COM would not occupy a position of such prominence.

• COM is dependent on the registry. This causes interesting deployment issues. Your applications cannot be copied from one machine to another without going through the registration process and defining key application paths. Most COM applications therefore cannot be deployed without some kind of installation package.

• COM components don't always play nice with each other. Versioning under COM is its own sort of hell. Over time, a new term was coined to describe this situation: DLL hell . In addition, bad installation practices that overwrite newer DLLs with older versions (due to a lack of version checking) and DLLs with the same name being installed in a common directory have all contributed to this problem.

Visual Basic: The Next Generation

Visual Basic .NET is a major advancement as a language and development platform. The years of cut-and-paste "inheritance" are finally over now that a real OOP infrastructure of implementation inheritance is available. Even though Visual Basic .NET offers several improvements over previous versions, it has retained its RAD roots. At the same time, the combination of Visual Basic .NET and the .NET Framework provides a wealth of features unmatched by classic Visual Basic.

More Info

Chapter 2 addresses many of the advanced language and platform features that are critical to large system implementations and maintenance.

Moving Beyond COM

Visual Basic .NET and the .NET common language runtime (CLR) address the limitations of COM in four key areas:

• Implementation inheritance

  Visual Basic .NET not only provides implementation inheritance, but it goes a step further. The architecture of the .NET Framework allows components to be extended through inheritance mechanisms. This addresses a major failing of classic COM development, and the glorious consequence is visual inheritance. Visual inheritance makes possible a whole new way to build components in your applications ”not only by leveraging existing code but by leveraging existing designs and enforcing development standards. Visual inheritance allows you to architect and build user interface elements that can extend existing user interface elements.

• Type-aware runtime

  COM is built on interfaces, so it has a form of runtime checking. You can query an object to determine whether it supports a particular interface, but you cannot inspect a COM object at run time to determine all of the interfaces it supports. With the .NET CLR, you can take any object and dynamically discover all of its interfaces, inheritance hierarchy, properties, methods , and fields.

• Reduced registry dependencies

  .NET components do not require the use of the system registry (unless they're registered for COM ”see Chapter 4 for more details). The recommended way to manage your Visual Basic .NET application's settings is through an application configuration file (App.Config), not the registry. On occasion you'll need to use the registry ”backward compatibility comes to mind ”but it's generally not a requirement for .NET applications.

• Side-by-side deployment

  Supporting two versions of the same application on the same machine used to require a lot of work. You had to ensure that newer versions of the same COM components wouldn't overwrite each other. (This was especially challenging because they were often stored in a common location). You also had to ensure that each component was versioned properly ”otherwise, the new registry settings for that component could cause applications that used the previous version to break. In Visual Basic .NET, this all changes. No longer does installing a new version of an application mean that your previous version will be killed ”unless you overwrite any of the application's dependencies. But this should not be a problem as long as you store the different versions of the application in different directories.

Good Coding Practices

Nothing can substitute for good coding practices. Despite the features of Visual Basic .NET and the .NET Framework that enable better application design and implementation, nothing can prevent someone from designing a poorly implemented application. Quite the contrary. With the .NET Framework being so new, it will take developers time to train and adjust to a new way of thinking. It is all too easy to fall into the trap of thinking in "the old ways," leading to some pretty poor designs. Unfortunately, this is an inevitability for any new platform and the .NET platform will not be any different.

Implicit vs. Explicit Programming

This is a point that I'll periodically revisit throughout the book and that you should burn into the back of your mind: explicit programming gooood; implicit programming baaad. Implicit programming can take many forms. But it can be summed up as a practice in which the intent of the code is not obvious, nor is it enforced. When I say the intent of the code is not obvious, I mean precisely that. The interfaces supported by a class give you no indication of how they should be properly used. Enforcement, on the other hand, is all about the original developer preventing unsupported use of a class. When you design classes, methods, and interfaces, you should always do so in a way that makes their intended use obvious and makes it difficult or impossible to use them in an unintended way.

From the OOP design perspective, this can mean several things. For example, if a class should not be inherited from, you should declare it NotInheritable . If a class should only be derived from, not instantiated , you should declare it with MustInherit . Methods should always define their parameters as specifically as possible. Using Object as a type provides flexibility but can also lead to errors.

When you declare regular variables , you should also use the most specific type possible. This will reduce the options other developers have when they use your libraries and will minimize the chances for mistakes. Explicit programming also lets you do more design-time validation of your code, which can save you a lot of headaches . Design-time validation is essential to the modern programmer. It essentially allows you to detect certain errors as you type, rather than having to first compile the application and then run it to detect errors. This can be a huge time-saver and reduces the potential for common types of programming errors.

More Info

I'll talk more about implicit programming in Chapter 2, where I'll also discuss the use of late binding.

Naming Conventions

Visual Basic .NET is, like all earlier versions of Visual Basic, case-insensitive. This can lead to poor or inconsistent variable and function names , but Microsoft has established a set of style guidelines for the .NET platform that are reasonably easy to follow.

In the past, the recommended form of naming more or less followed the rules of Hungarian notation. If you've ever dealt with variables that look like pszName or lpszClassName , you know what I'm talking about. Visual Basic was never so strict, but you do see variations on the theme. There were, and continue to be, several reasons for this usage in languages such as C++. First and foremost, you cannot evaluate types at run time. (COM objects do allow this through QueryInterface but in a limited way.) If a type is already known, you're in good shape ”hence the funny -looking variable names. The .NET Framework frees you from some of these problems. Through the miracle of reflection, you can always evaluate not only the Type (note the capital T ) of a variable but also all the types from which it's derived and all the interfaces it implements. This is intrinsic to the platform itself and alleviates the potential confusion of variable types.

More Info

Check out Chapter 6 for more information on runtime type checking and evaluation.

Given this new ability to evaluate types at run time, the designers of the NET Framework decided that they could do away with Hungarian notation ”it was never very pretty anyway ”and employ a more readable and user-friendly notation. The following sections describe the naming practices that Microsoft recommends for methods and variables. (This material is adapted from a paper entitled "Coding Techniques and Programming Practices" by Rob Caron. You can find the full document at http://www.msdn.microsoft.com/library/en-us/dnvsgen/html/cfr.asp.)

Methods

Follow these guidelines regarding methods:

• Avoid ambiguous names that are open to interpretation, such as Analyze() for a routine or xxK8 for a variable.

• In object-oriented languages, it is redundant to include class names in the name of class properties, as in Book.BookTitle . Instead, use Book.Title .

• Use the verb-noun method for naming routines that perform some operation on a given object, as in CalculateInvoiceTotal() .

• In languages that permit function overloading, all overloads should perform a similar function. For languages that do not permit function overloading, establish a naming standard that relates similar functions.

Variables

Follow these guidelines regarding variables:

• Append computation qualifiers ( Avg , Sum , Min , Max , or Index ) to the end of a variable name, where appropriate.

• Use customary opposite pairs in variable names, as in min/max , begin/end , and open/clos e.

• Most names are constructed by concatenating several words, so you should use mixed-case formatting to make them more readable. In addition, to help distinguish between variables and routines, use Pascal casing (where the first letter of each word is capitalized) for routine names, as in CalculateInvoiceTotal . For variable names, use camel casing, where the first letter of each word except the first is capitalized, as in documentFormatType .

• Boolean variable names should contain Is , which implies Yes/No or True/False values, as in fileIsFound .

• Avoid using terms such as Flag when you name status variables, which differ from Boolean variables in that they might have more than two possible values. For example, instead of documentFlag , use a more descriptive name such as documentFormatType .

• Use a meaningful name even for a short-lived variable that might appear in only a few lines of code. Use single-letter variable names, such as i or j , for short-loop indexes only.

• If you use the Hungarian naming convention or some derivative thereof, develop a list of standard prefixes for the project to help developers name variables consistently.

• For variable names, it can be useful to include notation that indicates the scope of the variable, such as using the prefix g_ for global variables and m_ for module-level variables in Visual Basic.

• Constants should be all uppercase, with underscores between words, as in NUM_DAYS_IN_WEEK . Also, begin groups of enumerated types with a common prefix, as in FONT_ARIAL or FONT_ROMAN .

  More Info

  You'll find an excellent document titled "Coding Techniques" at http://www.msdn.microsoft.com that describes the recommended programming practices for .NET development. Some of the information contained in the article I have also covered here, but the document provides a broader overview of the topic.

  
  

I l @ ve RuBoard