Bon exemple d'utilisation d'AppDomain

Question

Je reçois demandé sur les domaines d'application dans les entretiens, et je connais les principes de base:

• ils sont un niveau d'isolement au sein d'une application (ce qui les rend différents de demandes)
• ils peuvent avoir des threads (ce qui les rend différents de threads)
• exceptions dans un domaine d'application n'affectent pas l'autre
• domaines d'application ne peut pas accéder aux autres de la mémoire
• chaque domaine d'application peut avoir différentes de la sécurité

Je ne comprends toujours pas ce qui les rend nécessaires. Je suis à la recherche d'un raisonnable béton circonstance lorsque vous utilisez un.

Réponses:

• Code non fiable
  • Application de base protégés
    Non approuvé/3ème partie, les plugins sont empêchés de corruption de la mémoire partagée et les accès non-autorisé à un registre ou le disque dur par l'isolement dans l'appdomain séparé avec des restrictions de sécurité, la protection de l'application ou du serveur. par exemple ASP.NET et SQL Serveur hébergeant le code du composant
• Le code de confiance
  • La stabilité
    Demande segmentée en coffre-fort, indépendant des caractéristiques/fonctionnalités
  • La souplesse architecturale
    La liberté d'exécuter plusieurs applications au sein d'un seul CLR instance ou de chaque programme dans son propre.

Quelque chose d'autre?

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 AppDomain, isolant l'application.

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

Pour le 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

Answer 2

Un autre avantage de domaines d'application (comme vous l'avez mentionné dans votre question) est le code que vous chargez dans elle peut fonctionner avec différentes autorisations de sécurité. Par exemple, j'ai écrit une application dynamique des Dll chargées. J'ai été un instructeur et ceux-ci étaient des étudiants Dll, j'ai été chargement. Je ne voulais pas que certains esprits chagrins étudiant à effacer mon disque dur ou corrompus ma base de registre, j'ai donc chargé le code à partir de leurs Dll dans un autre domaine d'application qui n'ont pas d'e / s fichier de permissions ou autorisations de modification du registre ou même des autorisations pour afficher de nouvelles fenêtres (en fait, il a seulement eu les autorisations d'exécution).

Answer 3

Je pense que la principale motivation pour avoir des domaines d'application, c'est que le CLR concepteurs ont voulu un façon d'isoler le code managé sans encourir la charge de plusieurs processus Windows. A la CLR été à l'origine mis en œuvre sur le dessus de UNIX (d'où la création de plusieurs processus est beaucoup moins cher), les domaines d'application peuvent ne jamais avoir été inventé.

Aussi, bien que géré plug-in architectures dans les applications 3ème partie est certainement une bonne utilisation de domaines d'application, plus de raison d'exister est pour le bien-connu hôtes, tels que SQL Server 2005 et ASP.NET. Par exemple, un ASP.NET prestataire d'hébergement ne peuvent offrir de l'hébergement mutualisé solution qui prend en charge plusieurs sites de plusieurs clients tous sur la même zone de l'exécution en vertu d'un unique processus de Windows.

Answer 4

Si vous créez une application qui autorise les plug-ins tiers, vous pouvez les charger dans un AppDomain séparé 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 5

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

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