AppDomain, process and components...
This is a fundamental concept in .Net. In this short retrospective I try to offload following points:
1. What is AppDomain? Aslo a derived question: what is the difference between Appdomain and process?
2. Why we need AppDomain?
3. What is the design implication of Appdomain has on software?
So what is AppDomain? What is the difference between Appdomain and process?
From gotnotnet
“Application Domain is a construct in the CLR that is the unit of isolation for an application.” In non-.NET CLR environment, each running application is hosted by a process. There can be numerous processes launched of the same application and each process can only host ONE application. In contrast, .NET CLR introduces a light-way unit to load an application – AppDomain. Each AppDomain hosts one application, (or indeed assembly, component). Each process can have multiple AppDomains.
Why we need AppDomain?
AppDomain provides isolation around applications without the heavy cost associated with running an application within a process (address space, context, security...). In another word when addressing security context for example, it is wrapped around process unit. It relives each resident in an AppDomain from handling it themselves.
The isolation means:
• An application can be independently stopped.
• An application cannot directly access code or resources in another application.
• A fault in an application cannot affect other applications.
• Configuration information is scoped by application. This means that an application controls the location from which code is loaded and the version of the code that is loaded.
What is the design implication of AppDomain has on software?
AppDomain promotes a loose-coupled component-oriented programming mode.
The term component is probably one of the most overloaded terms in morden software engineering. From Wikipedia I found quite a few entries, which defines ‘component’ in different domain. Where it is related to computer science, it reads ‘A piece that makes up a whole, a part of an assembly’. Very abstract. In electronic component, it says ‘An electronic component is a basic electronic element usually packaged in a discrete form with two or more connecting leads or metallic pads. Components are intended to be connected together…’ This definition is more vivid to use as a metaphor here.
In .net a class *IS* a component. In the extreme form, one can compile a .net class into a binary assembly. Then CLR can load it into an AppDomain of a process.
From runtime process’ point of view, ‘traditional’ programming model/application is packaged to a monolithic binary block, regardless how it maps class diagram for business logic. Monolithic binary means they are tightly coupled. A change to one class can trigger a massive relinking of the entire application and necessitate retesting and redeployment of all other classes.
In contrast, a .net component based application is a collection of binary building blocks grouped by functionality. Each block contains one or more classes. At run time, each block is loaded to an AppDomain, together, they make up a process. If one of the component needs to be update, changes are contained to that component only. No existing client of the component requires recompilation or redeployment. An updated component can even be updated while a client application is running, as long as the component isn’t currently being used.
