Qu'est-ce qu'un AppDomain ? Quels sont les avantages des AppDomains ou pourquoi ? Microsoft a apporté le concept d'AppDomains, quel était le problème sans AppDomains ?
Veuillez préciser.
Réponses
Trop de publicités?
Un site AppDomain fournit une couche d'isolation au sein d'un processus. Tout ce que vous considérez habituellement comme étant "par programme" (variables statiques, etc.) est en fait "par domaine d'application". Ceci est utile pour :
- (vous pouvez décharger un plugin
AppDomainmais pas un assemblage sur unAppDomain) - la sécurité (vous pouvez exécuter un ensemble de codes avec des niveaux de confiance spécifiques)
- isolation (vous pouvez exécuter différentes versions d'assemblages, etc.)
Le problème est que vous devez utiliser le remoting, etc.
Voir MSDN pour plus d'informations. Pour être honnête, ce n'est pas quelque chose que vous devez manipuler très souvent.
George
Points
95
Un domaine d'application met en œuvre le concept d'un espace de mémoire virtuelle contigu qui contient le code et les ressources en mémoire peuvent être directement accessibles ou référencées.
Les domaines d'application séparés ne partagent pas d'espace mémoire et, par conséquent, un domaine d'application ne peut pas faire directement référence au contenu d'un autre domaine d'application. En particulier, les données doivent être transmises entre les AppDomains par un processus de copie par valeur. En particulier, les objets de référence, qui reposent sur des pointeurs et donc des adresses mémoire, doivent être d'abord sérialisés puis désérialisés dans l'AppDomain source et l'AppDomain destination, respectivement.
Auparavant, les limites de mémoire étaient mises en œuvre par des processus ; cependant, sur les systèmes Windows, la construction de processus est gourmande en ressources. Ils ont également une double fonction en tant que limites de threads. Les domaines d'application, en revanche, ne sont concernés que par les limites de la mémoire ou l'espace d'adressage. Les threads peuvent "circuler" entre les AppDomains (c'est-à-dire qu'une procédure peut invoquer un point d'entrée dans un autre AppDomain et attendre son retour, auquel cas on dit que le thread continue son exécution dans l'autre AppDomain).
Un avantage important est que le modèle de communication entre les domaines d'application reste essentiellement inchangé, que les domaines d'application soient dans le même processus, dans des processus différents ou sur des machines différentes : la sérialisation et la désérialisation.
Note 1 : la signification d'un thread traversant un AppDomain est celle d'un appel de méthode bloquant ou synchrone dans un autre AppDomain (par opposition à un appel non bloquant ou asynchrone qui continue sans attendre de réponse).
Note 2 : le stockage local de threads existe. Cependant, un meilleur nom aurait été App-Domain Thread Local Storage puisque les threads laissent leurs données derrière eux lorsqu'ils traversent les App-Domains mais les récupèrent lorsqu'ils reviennent : http://msdn.microsoft.com/en-us/library/6sby1byh.aspx
Brian Rasmussen
Points
68853
Les AppDomains peuvent être considérés comme des processus légers. Ils partagent plusieurs des caractéristiques d'un processus, par exemple, ils ont leurs propres copies de statiques, assemblages et ainsi de suite, mais ils sont contenus dans un seul processus. Du point de vue du système d'exploitation, un processus est simplement un processus, quel que soit le nombre d'AppDomains qu'il peut contenir.
Cependant, contrairement à un processus, un AppDomain n'a pas de threads à moins que vous ne les créiez explicitement. Un thread peut exécuter du code dans n'importe quel AppDomain.
Les AppDomains font partie du même processus et partagent donc le même tas géré. Ceci n'est généralement pas un problème puisque le modèle de programmation AppDomain empêche l'accès implicite entre AppDomains. Cependant, certaines références sont réellement partagées entre les AppDomains, comme les objets de type et les chaînes de caractères internées.
