XML as the .NET 'Meta-language' - Page 11

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.

Additional Benefits

The major benefits of .NET discussed thus far can be summarized as:

• Faster development (less to do, the system handles more)
• Lots of built-in functionality through a rich object model
• A variety of ways to interface and integrate with the outside world
• More reuse
• Easy to integrate different languages into one system
• Easier deployment
• Scalability
• Easy to build sophisticated development tools
• Interfaces well to existing software

There are a couple of additional benefits that are worth mentioning.

Fewer Bugs – Whole Classes of Bugs Will Disappear

The architecture and capabilities of the CLR wipe out whole classes of bugs. Memory leaks, failure to clean up at the end of execution, and other memory management related problems become non-existent (assuming the developers of the CLR take care of their part). Instancing of classes is handled automatically (no more CoCreateInstance), and they are managed throughout their lifecycle.

Potentially Better Performance

The built-in capabilities of the CLR are to be used almost universally. Microsoft knows that, for .NET to succeed, these capabilities must be reliable and efficient, and they have invested the efforts of their very best architects and developers to make that happen.

This heavy investment in system level code should have the result of speeding up performance for all but the most optimized of applications. Critical and frequently used functions, no matter how ordinary, will usually be optimized to the hilt in the CLR.

Some Potential Downsides

Nothing comes completely for free. Here are a couple of ways in which there is a price to be paid to get the advantages of .NET

Language Incompatibilities

Making languages work in this new framework usually means adjustment to the language syntax. This introduces compatibility problems in moving existing code into .NET. Visual Basic is a particular problem, as we shall see in Chapter 4.

Transparency of "Source Code"

The bytecodes in the Intermediate Language are much higher level than the processor instructions that programs are compiled into today. While we can disassemble a program in current environments, the assembler-based result is of limited use. .NET programs disassembled from IL, on the other hand, will more closely resemble actual source code. They will also contain the information needed to understand data structures. Such disassembled programs make algorithms and code processes more transparent than with current environments, making it more difficult to protect intellectual property. Microsoft may eventually build in some kind of encryption to remedy this problem, or perhaps third parties can introduce tools that obfuscate the code, but there are no known plans at this point.

Web Forms - Page 10
Introducing .NET
The First Step – Visual Studio.NET - Page 12