Bon exemple d'utilisation d'AppDomain

Question

On me pose régulièrement des questions sur AppDomains dans les interviews et je connais les bases :

• il s’agit d’un niveau d’isolement au sein d’une application (ce qui les différencie des applications)
• ils peuvent avoir des fils (ce qui les rend différents des fils)
Les
• exceptions dans un domaine d'application n'affectent pas les autres
• les domaines d'applications ne peuvent pas accéder à la mémoire de l'autre
• chaque domaine d'application peut avoir une sécurité différente

Je ne comprends toujours pas ce qui les rend nécessaires. Je recherche une circonstance concrète raisonnable lorsque vous en utiliseriez une.

Réponses:

• code non approuvé
• Application principale protégée
  Les plug-ins tiers / tiers ne sont pas autorisés à corrompre la mémoire partagée ni les accès non autorisés au registre ou au disque dur en les isolant dans un domaine d'application séparé avec des restrictions de sécurité, protégeant ainsi l'application ou le serveur. par exemple. Code de composant d'hébergement ASP.NET et SQL Server
• code de confiance
• Stabilité
  Application segmentée en fonctionnalités / fonctionnalités sûres et indépendantes
• Flexibilité architecturale
  Liberté d'exécution de plusieurs applications au sein d'une seule instance CLR ou de chaque programme distinct.

Autre chose?

Answer 1

La plus courante consiste probablement à charger des assemblys contenant du code de plug-in provenant de tiers non approuvés. Le code s'exécute dans son propre domaine AppDomain, isolant ainsi l'application.

De plus, il n'est pas possible de décharger un assemblage particulier, mais vous pouvez décharger AppDomains.

Pour un récapitulatif complet, Chris Brumme a publié une énorme entrée de blog à ce sujet:

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

https://devblogs.microsoft.com/cbrumme/appdomains-application- domaines /

Answer 2

Un autre avantage d'AppDomains (comme vous l'avez mentionné dans votre question) est que le code que vous chargez dans celui-ci peut s'exécuter avec des autorisations de sécurité différentes. Par exemple, j'ai écrit une application qui a chargé dynamiquement des DLL. J'étais instructeur et c'étaient des DLL d'étudiants que je chargeais. Je ne voulais pas qu'un étudiant mécontent efface mon disque dur ou ma base de registres, alors j'ai chargé le code de leurs DLL dans un AppDomain séparé qui ne disposait pas d'autorisations d'entrée-fichier ni d'autorisations d'édition de registre, ni même d'autorisations d'affichage de nouvelles fenêtres. (il n’avait en fait que des autorisations d’exécution).

Answer 3

Je pense que la principale motivation pour utiliser AppDomains est que les concepteurs de CLR souhaitaient un moyen d'isoler le code managé sans entraîner de surmenage en performances de la part de plusieurs processus Windows. Si le CLR avait été implémenté à l'origine sous UNIX (où la création de plusieurs processus coûte nettement moins cher), AppDomains n'aurait peut-être jamais été inventé.

De même, bien que les architectures de plug-ins gérés dans les applications tierces constituent définitivement une bonne utilisation d'AppDomains, leur raison majeure est qu'elles existent pour des hôtes connus tels que SQL Server 2005 et ASP.NET. Par exemple, un fournisseur d’hébergement ASP.NET peut offrir une solution d’hébergement partagé prenant en charge plusieurs sites de plusieurs clients, tous sur le même boîtier, s’exécutant sous un même processus Windows.

Answer 4

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

Si votre application consiste en un processus central, qui génère ensuite les "fonctionnalités". dans des domaines d'application distincts, vous pouvez empêcher un crash global si l'un d'entre eux se comportait mal.

Answer 5

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

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

Answer 6

D'après ce que j'ai compris, AppDomain est conçu pour permettre à l'entité hébergeant (système d'exploitation, base de données, serveur, etc.) la liberté d'exécuter plusieurs applications au sein d'une seule instance de CLR ou de chaque programme. C’est donc un problème pour l’hôte plutôt que pour le développeur d’applications.

Cela se compare avantageusement à Java où vous avez toujours une 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.

Answer 7

Je vois 2 ou 3 principaux cas d'utilisation pour la création de domaines d'application distincts:

1) Isolement de type processus avec utilisation réduite des ressources et temps système. Par exemple, voici ce que fait ASP.NET: il héberge chaque site Web dans un domaine d'application distinct. S'il utilisait différents threads dans le même domaine d'application, le code de différents sites Web pourrait alors interférer. S'il hébergeait différents sites Web dans différents processus, il utiliserait beaucoup de ressources et la communication interprocessus serait relativement difficile par rapport à la communication intra-processus.

2) L'exécution de code non approuvé dans un domaine d'application distinct doté d'autorisations de sécurité particulières (cela est en fait lié à la 1ère raison). Comme on l'a déjà dit, vous pouvez charger des plugins tiers ou des dll non fiables dans des domaines d'application distincts.

3) Possibilité de décharger des assemblages afin de réduire l'utilisation inutile de la mémoire. Malheureusement, il est impossible de décharger un assembly d'un domaine d'application. Ainsi, si vous chargez un grand assemblage dans votre domaine d'application principal, le seul moyen 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'assemblys dans un domaine d'application distinct et le déchargement de ce domaine d'application lorsque ces assemblages ne sont plus nécessaires constituent une solution à ce problème.