The Basics in .NET framework

Draw QR Code ISO/IEC18004 in .NET framework The Basics

database techniques available including server-side and client-side cursors, disconnected resultsets, and batch updates ADO.NET focuses mainly on discon nected resultsets (called DataSets in ADO.NET terminology) and currently offers no support for server-side cursors. The DataSet object is much more powerful than the ADO Recordset object and can store data coming from multiple tables, in the same database or different databases. You can create relationships among different data tables, and you can import or export both the data and the metadata as XML. The next two layers are ASP.NET and Windows Forms, which are located at the same level in the diagram. These portions of the framework contain all the classes that can generate the user interface in a browser in the former case and using standard Win32 windows in the latter case. As I explained earlier, ASP.NET comprises both Web Forms and Web ser vices. Even though these two portions appear at the same level in the diagram, and in spite of their similarities, these technologies are very different. Web Forms run on the server and produce HTML code that s rendered in a browser on the client (which can run on virtually any operating system), whereas Windows Forms run on the client (and this client must be a Windows machine). However, you can mix them in the same application, to some extent at least. For example, you can have a .NET application that queries a remote Web service through the Internet and displays its result using Windows Forms. The .NET Framework class library consists of a collection of assemblies, each one compris ing one or more DLLs. For example, ADO.NET is contained in the System.Data.dll assem bly, and the XML portion of the framework is contained in the System.Xml.dll assembly. You can see all the assemblies that make up the .NET Framework class library by browsing the Assembly directory under the main Windows directory, as you can see in Figure 1-2.

Figure 1-2 The Windows\Assembly directory of a computer on which both versions 1.0 and 1.1 of the .NET Framework have been installed

1:

The Common Language Specification (CLS) is a set of specifications that Microsoft has supplied to help compiler vendors. These specifications dictate the minimum group of features that a .NET language must have, such as support for signed integers of 16, 32, or 64 bits, zero-bound arrays, and structured exception handling. A compiler vendor is free to create a language that exceeds these specifications for example, with unsigned integers or arrays whose lowest index is nonzero but a well-designed application should never rely on these non-CLS-compliant features when communicating with other .NET components because the other component might not recognize them. Interestingly, Visual Basic .NET matches the CLS specifications almost perfectly, so you don t have to worry about using non-CLS-compliant features in your applications. C# developers can use a Visual Studio .NET option to ensure that only CLS-compliant features are exposed to the outside. At the top of the diagram in Figure 1-1 are the Programming languages that comply with CLS. Microsoft offers the following languages: Visual Basic .NET, C#, Managed C++, Visual J#, and JScript. Many other languages have been released by other vendors or are under development, including Perl, COBOL, Smalltalk, Eiffel, Python, Pascal, and APL, plus a few that to be honest I ve never heard of. All the .NET languages produce managed code, which is code that runs under the con trol of the runtime. Managed code is quite different from the native code produced by traditional compilers, which is now referred to as unmanaged code. Of all the new lan guage offerings from Microsoft, only C++ can produce both managed and unmanaged code, but even C++ developers should resort to unmanaged code only if strictly nec essary for example, for doing low-level operations or for performance reasons because only managed code gets all the benefits of the .NET platform. Because all the .NET languages from Microsoft or other vendors target the CLS and use the classes and the data types in the .NET Framework, they re more similar than languages used to be in the past. For example, all .NET languages handle errors using structured exception handlers and support 16-bit, 32-bit, and 64-bit signed integers. Another example: because the common language runtime and the CTS support only single inheritance (which means that a type can inherit only from one type), all lan guages support single inheritance; there s no room for multiple inheritance in the .NET world. The similarity among all languages has three important consequences. First, the execution speed of all languages tends to be the same, as I have already explained, so your choice of language should be based on other factors, such as produc tivity. Second, language interoperability is ensured because all the languages use the same data types and the same way to report errors, so you can write different portions of an application with different languages without worrying about their integration. Third, and maybe most important from the perspective of us developers: learning a new .NET language is surprisingly effortless if you ve already mastered another .NET

Part I: