Now that you are familiar with the major goals of the .NET Framework, let’s briefly examine its architecture. As you can see in Figure 1-2, the .NET Framework sits on top of the operating system, which can be a few different flavors of Windows,[3] and consists of a number of components. (Each of these components is discussed in greater detail starting with Chapter 4, as described in the Preface.) .NET is essentially a system application that runs on Windows.
The most important component of the Framework is something called the CLR. If you are a Java programmer, think of the CLR as the .NET equivalent of the Java Virtual Machine ( JVM). If you don’t know Java, think of the CLR as the heart and soul of the .NET architecture. At a high level, the CLR activates objects, performs security checks on them, lays them out in memory, executes them, and garbage-collects them.
Conceptually, the CLR and the JVM are similar in that they are both runtime infrastructures that abstract the underlying platform differences. However, while the JVM currently supports just the Java language, the CLR supports all languages that can be represented in the Common Intermediate Language (CIL). The JVM executes bytecode, so it could technically support many different languages, too. Unlike Java’s bytecode, though, IL is never interpreted. Another conceptual difference between the two infrastructures is that Java code runs on multiple platforms with a JVM, whereas .NET code runs only on the Windows platforms with the CLR (at the time of this writing). Microsoft has submitted the Common Language Infrastructure (CLI), which is functional a subset of the CLR, to ECMA, so a third-party vendor could theoretically implement a CLR for a platform other than Windows. For more information on third-party vendors, see Appendix A.
In Figure 1-2, the layer on top of the CLR is a set of framework base classes. This set of classes is similar to the set of classes in STL, MFC, ATL, or Java. These classes support rudimentary input and output functionality, string manipulation, security management, network communications, thread management, text management, reflection functionality, and collections functionality, as well as other functions.
On top of the framework base classes is a set of classes that extend the base classes to support data management and XML manipulation. The data classes support persistent data management—data that is stored on backend databases. These classes include the Structured Query Language (SQL) classes to let you manipulate persistent data stores through a standard SQL interface. Similar to the SQL classes, the set of classes called ADO.NET allow you to manipulate persistent data. Alongside of the data classes, the .NET Framework supports a number of classes to let you manipulate XML data, perform XML searching, and perform XML translations.
Classes in three different technologies (including Web Services, Web Forms, and Windows Forms) extend the framework base classes and the data and XML classes. Web Services include a number of classes that support the development of lightweight distributed components, which will work even in the face of firewalls and NAT software. These components support plug-and-play across cyberspace, because Web Services employ standard HTTP and SOAP.
Web Forms include a number of classes that allow you to rapidly develop web Graphical User Interface (GUI) applications. If you’re currently developing web applications with Visual Interdev, you can think of Web Forms as a facility that allows you to develop web GUIs using the same drag-and-drop approach as if you were developing the GUIs in Visual Basic. Simply drag and drop controls onto your Web Form, double-click on a control, and write the code to respond to the associated event.
Windows Forms support a set of classes that allow you to develop native- Windows GUI applications. You can think of these classes collectively as a much better version of MFC because they support easier GUI development and provide a common, consistent interface that can be used in all languages.
In the next chapter, we examine the internals of the CLR and how it supports and executes .NET components, formally called assemblies in .NET.