Pergunta

Eu recebo questionado sobre AppDomains em entrevistas, e Eu sei o básico :

  • são um nível de isolamento dentro de uma aplicação (tornando-os diferentes de aplicações)
  • eles podem ter threads (tornando-os diferentes de threads)
  • exceções em um appdomain não afetam outra
  • AppDomains não pode acessar a memória do outro
  • cada appdomain pode ter segurança diferente

Eu ainda não entendi o que os torna necessário. Eu estou procurando uma circunstância concreta razoável quando você usaria um.

Respostas:

  • código não confiável
    • aplicativo principal protegido
      Não confiáveis ??/ 3rd plugins de terceiros são proibidos de corromper a memória compartilhada e acesso não autorizado ao registro ou disco rígido pelo isolamento em appdomain separado com restrições de segurança, protegendo a aplicação ou servidor. por exemplo. ASP.NET e SQL Server que hospeda o código do componente
  • código confiável
    • Estabilidade
      Aplicação segmentado em seguro, características independentes / funcionalidade
    • flexibilidade Architectural
      Liberdade de executar múltiplas aplicações dentro de uma instância CLR única ou cada programa em seu próprio.

Mais alguma coisa?

Foi útil?

Solução

Provavelmente, o mais comum é a conjuntos de carga que contêm plug-in de código a partir de partes não confiáveis. O código é executado em seu próprio AppDomain, isolando a aplicação.

Além disso, não é possível descarregar um conjunto particular, mas você pode descarregar AppDomains.

Para o resumo completo, Chris Brumme teve uma entrada de blog enorme sobre isso:

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

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

Outras dicas

Outra vantagem de AppDomains (como você mencionou na sua pergunta) é o código que você carrega para ele pode ser executado com diferentes permissões de segurança. Por exemplo, eu escrevi um aplicativo que dinamicamente carregado DLLs. Eu era um instrutor e estes foram estudante DLLs eu estava carregamento. Eu não queria que algum estudante descontente para acabar com o meu disco rígido ou corrompido meu registro, então eu carregado o código de seus DLLs em um AppDomain separado que não têm permissões de arquivo IO ou registro editar permissões ou mesmo permissões para mostrar novas janelas (que na verdade só tinha permissões de execução).

Eu acho que a principal motivação para ter AppDomains é que os designers CLR queria uma maneira de isolar o código gerenciado sem incorrer a sobrecarga de vários processos do Windows desempenho. Tinha o CLR sido originalmente implementado em cima do UNIX (onde a criação de vários processos é significativamente menos caro), AppDomains pode nunca ter sido inventado.

Além disso, enquanto plug-in conseguiu arquiteturas em aplicações 3rd party é definitivamente um bom uso de AppDomains, a razão maior do que eles existem é para os anfitriões bem conhecidas como SQL Server 2005 e ASP.NET. Por exemplo, um provedor de hospedagem ASP.NET pode oferecer uma solução de hospedagem compartilhada que suporta vários sites de vários clientes todos na mesma máquina rodando sob um único processo do Windows.

App Domínios são grandes para a estabilidade do aplicativo.

Ao ter o seu aplicativo consiste em um processo central, que então desova fora "características" em AppDomains separados, você pode pode prevenir um acidente global deve um deles se comportam mal.

Se você criar um aplicativo que permite 3-parte plug-ins, você pode carregar os plug-ins em um AppDomain separado para que a sua principal aplicação é segura a partir do código desconhecido.

ASP.NET também usa AppDomains separados para cada aplicativo web dentro de um único processo de trabalho.

Pelo que entendi AppDomain são projetados para permitir que a entidade hospedagem (OS, DB, servidor etc ...) a liberdade de executar múltiplas aplicações dentro de uma instância CLR única ou cada programa em sua própria. Assim seu um problema para o anfitrião em vez do desenvolvedor do aplicativo.

Isso se compara favoravelmente com Java, onde você sempre tem uma JVM por aplicação, muitas vezes resultando em muitas instâncias da JVM correndo lado a lado com recursos duplicados.

Eu vejo 2 ou 3 principais casos de uso para a criação de domínios de aplicação distintos:

1) Processo de isolamento semelhante com a utilização de recursos de baixo e em cima. Por exemplo, isso é o que ASP.NET faz - ele hospeda cada site em um domínio aplicativo separado. Se ele é utilizado diferentes segmentos no domínio de aplicação única em seguida, o código de sítios diferentes podem interferir uns com os outros. Se hospedado sites diferentes em diferentes processos -. Ele iria usar muitos recursos e também a comunicação entre processos é relativamente difícil comparar a comunicação inprocess

2) Executando código não confiável em um domínio de aplicação em separado com determinadas permissões de segurança (este é realmente relacionados a 1º de razão). Como as pessoas já disse, você pode carregar plugins 3rd party ou DLLs não confiáveis ??em domínios de aplicação distintos.

3) Capacidade de montagens de descarregamento para reduzir o uso de memória desnecessária. Infelizmente, não há nenhuma maneira a descarregar uma montagem a partir de um domínio de aplicação. Então, se você carregar algum grande montagem para seu domínio principal do aplicativo, a única maneira de liberar a memória correspondente depois que a montagem não é mais necessário é encerrar a sua aplicação. Carregando montagens em um domínio aplicativo separado e descarga que domínio de aplicação quando esses conjuntos não são mais necessários é uma solução para este problema.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top