Bon exemple d’utilisation d’AppDomain

Je continue à être interrogé sur AppDomains dans les interviews, et je connais les bases :

  • ils sont un niveau d’isolement dans une application (ce qui les rend différents des applications)
  • ils peuvent avoir des threads (ce qui les rend différents des threads)
  • les exceptions dans un domaine d’application n’affectent pas un autre
  • les domaines d’application ne peuvent pas accéder à la mémoire des autres
  • chaque domaine d’application peut avoir une sécurité différente

Je n’ai toujours pas ce qui les rend nécessaires. Je cherche une circonstance concrète raisonnable lorsque vous en utiliseriez un.

Réponses:

  • Code non fiable
    • Application principale protégée
      Les plug-ins tiers / non fiables ne peuvent pas corrompre la mémoire partagée et l’access non autorisé au registre ou au disque dur par isolation dans un domaine distinct avec des ressortingctions de sécurité, protégeant ainsi l’application ou le serveur. Par exemple, ASP.NET et SQL Server hébergeant le code du composant
  • Code de confiance
    • La stabilité
      Application segmentée en fonctionnalités / fonctionnalités sûres et indépendantes
    • Flexibilité architecturale
      Liberté d’exécuter plusieurs applications dans une seule instance CLR ou dans chaque programme.

Rien d’autre?

La plus courante consiste probablement à charger des assemblages contenant du code plug-in provenant de parties non fiables. Le code s’exécute dans son propre AppDomain, isolant l’application.

En outre, il n’est pas possible de décharger un assembly particulier, mais vous pouvez décharger AppDomains.

Pour le récapitulatif complet, Chris Brumme a eu un énorme blog à ce sujet:

http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx

Un autre avantage d’AppDomains (comme vous l’avez mentionné dans votre question) est que le code que vous chargez peut s’exécuter avec des permissions de sécurité différentes. Par exemple, j’ai écrit une application qui chargeait dynamicment des DLL. J’étais un instructeur et il s’agissait de DLL d’étudiants que je chargeais. Je ne voulais pas qu’un élève mécontent efface mon disque dur ou corrompe mon registre. J’ai donc chargé le code de leurs DLL dans un AppDomain distinct qui ne disposait pas d’permissions d’E / S de fichier ou d’permissions d’édition de registre (en fait, il n’avait que des permissions d’exécution).

Je pense que la principale motivation pour avoir AppDomains est que les concepteurs de CLR voulaient un moyen d’isoler le code managé sans engendrer la surcharge de performances de plusieurs processus Windows. Si le CLR avait été initialement implémenté au-dessus d’UNIX (où la création de plusieurs processus est nettement moins coûteuse), AppDomains n’aurait peut-être jamais été inventé.

De plus, bien que les architectures de plug-in gérées dans les applications tierces soient certainement une bonne utilisation d’AppDomains, la plus grande raison de leur existence concerne les hôtes bien connus tels que SQL Server 2005 et ASP.NET. Par exemple, un fournisseur d’hébergement ASP.NET peut proposer une solution d’hébergement partagé prenant en charge plusieurs sites provenant de plusieurs clients, tous exécutés dans un même processus Windows.

Les domaines d’application sont parfaits pour la stabilité des applications.

En faisant en sorte que votre application se compose d’un processus central, qui génère ensuite des «fonctionnalités» dans des domaines d’applications distincts, vous pouvez empêcher un plantage global si l’un d’eux se comporte mal.

Si vous créez une application qui autorise des plug-ins tiers, vous pouvez charger ces plug-ins dans un AppDomain distinct afin que votre application principale soit protégée du code inconnu.

ASP.NET utilise également des AppDomains distincts pour chaque application Web au sein d’un même processus de travail.

Si je comprends bien, AppDomain est conçu pour permettre à l’entité hôte (OS, DB, Serveur, etc.) d’exécuter plusieurs applications au sein d’une même instance CLR ou de chaque programme. C’est donc un problème pour l’hôte plutôt que pour le développeur de l’application.

Cela se compare favorablement à Java où vous avez toujours 1 machine virtuelle Java par application, ce qui entraîne souvent l’exécution simultanée de nombreuses instances de la machine virtuelle Java avec des ressources dupliquées.

Je vois 2 ou 3 cas d’utilisation principaux pour créer des domaines d’application distincts:

1) Isolation semblable à un processus avec une faible utilisation des ressources et une surcharge. Par exemple, c’est ce que fait ASP.NET: il héberge chaque site Web dans un domaine d’application distinct. S’il utilisait des threads différents dans le domaine d’application unique, le code de différents sites Web pourrait interférer l’un avec l’autre. Si elle hébergeait différents sites Web dans différents processus, elle utiliserait beaucoup de ressources et les communications interprocessus seraient relativement difficiles à comparer aux communications en cours.

2) Exécuter du code non fiable dans un domaine d’application distinct avec des permissions de sécurité particulières (ceci est en réalité lié à la 1ère raison). Comme nous l’avons déjà dit, vous pouvez charger des plug-ins tiers ou des DLL non fiables dans des domaines d’application distincts.

3) Possibilité de décharger des assemblages pour réduire l’utilisation inutile de la mémoire. Malheureusement, il n’existe aucun moyen de décharger un assembly à partir d’un domaine d’application. Donc, si vous chargez un gros assemblage sur votre domaine d’application principal, la seule façon de libérer la mémoire correspondante après que cet assemblage n’est plus nécessaire est de fermer votre application. Le chargement d’assemblages dans un domaine d’application distinct et le déchargement de ce domaine d’application lorsque ces assemblys ne sont plus nécessaires constituent une solution à ce problème.