Thursday, December 12, 2024

.NET: The Web’s New DNA, Part Two

Before we can delve into actually building a Web Application I need to describe the basics of the .Net Frameworks structure. There will be many references to parts of this structure throughout these tutorials and as you come across these references, the nature and purpose of this structure will become clearer to you. This description is intended to familiarize you with the overall concepts involved and it is not necessary for you to remember all its details.

There are two main components that make up the .Net Framework. These are the Common Language Runtime and the .Net Framework Class Library. The Common Language Runtime (or CLR as it is usually referred to) is the foundation of the .Net Framework. It manages the memory that .Net code uses; it manages threads (more about them later); it polices code to ensure accuracy, robustness and security. Code that runs under the management of the CLR is known as Managed Code. The Class Library is a collection of code routines that can be used in the construction of programs designed for the Dot Net Architecture (DNA) and targeted for the CLR. The Class Library is comprehensive and greatly simplifies the construction of DNA applications.

Depending on whether a Managed Code component comes from somewhere on the Internet, or somewhere inside a corporate network or from the local computer (and a few other factors) the CLR assigns a trust level to the component. This trust level determines whether the component will be allowed access to local resources such as data stored on the local disks, the Windows registry or other security sensitive resources.

With the CLR enforcing security in this way, a user can safely allow a component that is embedded in a Web page to play a movie or some other such function, safe in the knowledge that it cannot gain access to their files. Since the function of the code could involve considerable interaction between the user and various data elements on the web page, which elements could reside in a database on the server system, the features of the web application can be rich indeed!

The CLR uses a system called the Common Type System to control data typeing. If a data element contains the value apple, for example, it would not make sense to use it in a mathematical operation. It is the wrong type of data for that type of operation. Preventing the attempt to perform an operation on the wrong type of data is what is referred to as data type control. Using the CTS, data carries its own type description which enables the CLR to enforce data type safety. Data type errors are a common source of program execution failures. Thus this type management helps to ensure the robustness of the managed code.

The CLR similarly manages object references. When a Managed Code component references an object (more on Objects later), the CLR manages all memory associated with the object reference. When the object is no longer needed, the CLR releases the associated memory. Programs that do not have the benefit of such management are prone to errors caused by invalid references to memory. Systems also suffer when a program does not release some memory it had allocated. This could happen, for example, when there is a sudden program termination caused by an execution error. Since the program is no longer around to release the memory it remains allocated indefinitely. This is called memory leakage. The cumulative effect can bring down a server when there is not enough available memory left for operation. Since the CLR manages the memory, the orphaned allocation can be automatically released.

Code that targets the CLR (i.e. it is designed for the CLR) all conforms to the same set of rules regardless of the language in which it was written. This means that components that were written in one language can readily be reused by, or can interact with, code written in another language. As long as the language compiler is one that targets the CLR it does not matter which language a programmer chooses to use. The resulting code can share all its components with other CLR targeted programs. While it might not be the best idea to use a variety of languages in a single application because of the resulting potential for maintenance difficulties, this feature does mean that a programmer can reuse an existing component even though it was written in some other language. There is no point in reinventing the wheel! This reusability can greatly reduce the time it takes to develop an application.

The CLR also supports interoperation between managed code and unmanaged code. Unmanaged code is code that does not target the CLR, such as code that was written prior to the DNAs release. This includes COM components and DLLs, which are types of objects commonly found in existing systems. This interoperability means that existing code can be used without having to be re-written.

Under the hood features of the CLR, including something called the Just-In-Time, or JIT compiler, are designed to provide very high performance. JavaScript is an example of interpreted code. It is translated (interpreted), line by line, into executable code as it is being run. The JIT compiler means that CLR managed code runs in the machine language of the system on which it is running, and does not have to be interpreted. While it is not essential to know this when developing your dot Net applications, it is comforting to think that your application will beat the shirt off the performance of traditional web applications while providing a much richer interactive experience at the same time.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Popular Articles

Featured