Buon esempio di utilizzo di AppDomain

Question

Continuo a ricevere domande su AppDomains nelle interviste e Conosco le basi:

• sono un livello di isolamento all'interno di un'applicazione (rendendoli diversi dalle applicazioni)
• possono avere thread (rendendoli diversi dai thread)
• le eccezioni in un dominio app non influiscono su un altro
• i domini app non possono accedere alla memoria degli altri
• ogni dominio app può avere una sicurezza diversa

Ancora non capisco cosa li renda necessari.Sto cercando una circostanza concreta e ragionevole in cui ne useresti una.

Risposte:

• Codice non attendibile
• Applicazione principale protetta
  Ai plugin non attendibili/di terze parti viene impedito di danneggiare la memoria condivisa e l'accesso non autorizzato al registro o al disco rigido mediante l'isolamento in un dominio app separato con restrizioni di sicurezza, proteggendo l'applicazione o il server.per esempio.Codice del componente hosting ASP.NET e SQL Server
• Codice affidabile
• Stabilità
  Applicazione segmentata in caratteristiche/funzionalità sicure e indipendenti
• Flessibilità architettonica
  Libertà di eseguire più applicazioni all'interno di una singola istanza CLR o di ciascun programma a sé stante.

Qualunque altra cosa?

Answer 1

Probabilmente il più comune è caricare assembly che contengono codice plug-in di parti non attendibili.Il codice viene eseguito nel proprio AppDomain, isolando l'applicazione.

Inoltre, non è possibile scaricare un particolare assembly, ma puoi scaricare AppDomains.

Per un resoconto completo, Chris Brumme ha scritto un enorme post sul blog su questo argomento:

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

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

Answer 2

Un altro vantaggio di AppDomains (come hai menzionato nella tua domanda) è che il codice che carichi può essere eseguito con autorizzazioni di sicurezza diverse.Ad esempio, ho scritto un'app che caricava dinamicamente le DLL.Ero un istruttore e queste erano le DLL degli studenti che stavo caricando.Non volevo che qualche studente scontento cancellasse il mio disco rigido o corrompesse il mio registro, quindi ho caricato il codice dalle loro DLL in un AppDomain separato che non aveva autorizzazioni di I/O file o autorizzazioni di modifica del registro o addirittura autorizzazioni per visualizzare nuove finestre (in realtà aveva solo i permessi di esecuzione).

Answer 3

Penso che la motivazione principale per avere AppDomains sia che i progettisti CLR volevano un modo per isolare il codice gestito senza incorrere nel sovraccarico prestazionale di più processi Windows.Se CLR fosse stato originariamente implementato su UNIX (dove la creazione di più processi è significativamente meno costosa), AppDomains probabilmente non sarebbe mai stato inventato.

Inoltre, sebbene le architetture plug-in gestite nelle app di terze parti costituiscano sicuramente un buon uso di AppDomain, il motivo principale per cui esistono è per host noti come SQL Server 2005 e ASP.NET.Ad esempio, un provider di hosting ASP.NET può offrire una soluzione di hosting condiviso che supporta più siti di più clienti tutti sulla stessa macchina in esecuzione con un unico processo Windows.

Answer 4

I domini delle app sono ottimi per la stabilità delle applicazioni.

Facendo in modo che la tua applicazione sia costituita da un processo centrale, che quindi genera "funzionalità" in domini app separati, puoi prevenire un arresto anomalo globale nel caso in cui uno di essi si comporti in modo anomalo.

Answer 5

Se crei un'applicazione che consente plug-in di terze parti, puoi caricare tali plug-in in un AppDomain separato in modo che l'applicazione principale sia al sicuro da codice sconosciuto.

ASP.NET utilizza anche AppDomain separati per ogni applicazione Web all'interno di un singolo processo di lavoro.

Answer 6

A quanto ho capito, gli AppDomain sono progettati per consentire all'entità hosting (sistema operativo, DB, server ecc...) la libertà di eseguire più applicazioni all'interno di una singola istanza CLR o ciascun programma nel proprio.Quindi è un problema per l'host piuttosto che per lo sviluppatore dell'applicazione.

Ciò si confronta favorevolmente con Java in cui hai sempre 1 JVM per applicazione, spesso con il risultato che molte istanze della JVM vengono eseguite fianco a fianco con risorse duplicate.

Answer 7

Vedo 2 o 3 casi d'uso principali per la creazione di domini applicativi separati:

1) Isolamento simile a un processo con basso utilizzo delle risorse e sovraccarico.Ad esempio, questo è ciò che fa ASP.NET: ospita ciascun sito Web in un dominio applicazione separato.Se utilizzasse thread diversi nel singolo dominio dell'applicazione, il codice di diversi siti Web potrebbe interferire tra loro.Se ospitasse siti Web diversi in processi diversi, utilizzerebbe molte risorse e anche la comunicazione tra processi è relativamente difficile rispetto alla comunicazione inprocess.

2) Esecuzione di codice non attendibile in un dominio applicazione separato con particolari autorizzazioni di sicurezza (questo è in realtà correlato al primo motivo).Come già detto, potresti caricare plug-in di terze parti o DLL non attendibili in domini applicativi separati.

3) Possibilità di scaricare gli assembly per ridurre l'utilizzo non necessario della memoria.Sfortunatamente non è possibile scaricare un assembly da un dominio dell'applicazione.Pertanto, se carichi un grosso assembly nel dominio dell'applicazione principale, l'unico modo per liberare la memoria corrispondente dopo che l'assembly non è più necessario è chiudere l'applicazione.Il caricamento degli assembly in un dominio dell'applicazione separato e lo scaricamento del dominio dell'applicazione quando tali assembly non sono più necessari rappresenta una soluzione a questo problema.