.net - Buen ejemplo de uso de AppDomain
(7)
Creo que la principal motivación para tener AppDomains es que los diseñadores de CLR querían una manera de aislar el código administrado sin incurrir en la sobrecarga de rendimiento de múltiples procesos de Windows. Si el CLR se hubiera implementado originalmente sobre UNIX (donde la creación de procesos múltiples es significativamente menos costosa), es posible que AppDomains nunca se haya inventado.
Además, aunque las arquitecturas de plug-ins administradas en aplicaciones de terceros son definitivamente un buen uso de AppDomains, la razón principal por la que existen es para hosts conocidos como SQL Server 2005 y ASP.NET. Por ejemplo, un proveedor de alojamiento ASP.NET puede ofrecer una solución de alojamiento compartido que admita múltiples sitios de múltiples clientes, todo en la misma caja que se ejecuta en un único proceso de Windows.
Me siguen preguntando sobre AppDomains en entrevistas, y sé lo básico :
- son un nivel de aislamiento dentro de una aplicación (que los hace diferentes de las aplicaciones)
- pueden tener hilos (haciéndolos diferentes de los hilos)
- excepciones en un dominio de aplicación no afectan a otro
- Los appdominios no pueden acceder a la memoria de los demás
- cada dominio de aplicación puede tener una seguridad diferente
Todavía no entiendo lo que los hace necesarios. Estoy buscando una circunstancia concreta razonable cuando usaría uno.
Respuestas
- Código no confiable
- Aplicación principal protegida
Los complementos no confiables / de terceros tienen prohibido dañar la memoria compartida y el acceso no autorizado al registro o al disco duro mediante el aislamiento en un dominio de aplicación separado con restricciones de seguridad, protegiendo la aplicación o el servidor. por ejemplo, código de componente de alojamiento ASP.NET y SQL Server - Código de confianza
- Estabilidad
Aplicación segmentada en funciones / funcionalidades seguras e independientes - Flexibilidad arquitectónica
Libertad para ejecutar múltiples aplicaciones dentro de una única instancia CLR o cada programa en sí mismo.
¿Algo más?
Los dominios de aplicaciones son excelentes para la estabilidad de la aplicación.
Al hacer que su aplicación consista en un proceso central, que luego genera "características" en appdomains separados, puede evitar un bloqueo global en caso de que alguno de ellos se comporte mal.
Otro beneficio de AppDomains (como mencionó en su pregunta) es que el código que carga puede ejecutarse con diferentes permisos de seguridad. Por ejemplo, escribí una aplicación que dinámicamente cargó DLL. Yo era instructor y estos eran archivos DLL de estudiantes que estaba cargando. No quería que un estudiante descontento borrara mi disco duro o corrompiera mi registro, así que cargué el código de sus DLL en un AppDomain separado que no tenía permisos IO de archivo o permisos de edición de registro o incluso permisos para mostrar ventanas nuevas (en realidad solo tenía permisos de ejecución).
Probablemente el más común es cargar ensamblajes que contienen código de complemento de partes que no son de confianza. El código se ejecuta en su propio AppDomain, aislando la aplicación.
Además, no es posible descargar un ensamblaje en particular, pero puede descargar AppDomains.
Para el resumen completo, Chris Brumme tuvo una entrada de blog masiva sobre esto:
Según tengo entendido, AppDomain está diseñado para permitir a la entidad de alojamiento (SO, DB, Servidor, etc ...) la libertad de ejecutar múltiples aplicaciones dentro de una única instancia de CLR o cada programa en sí mismo. Por lo tanto, es un problema para el host en lugar del desarrollador de la aplicación.
Esto se compara favorablemente con Java, donde siempre tiene 1 JVM por aplicación, lo que a menudo resulta en muchas instancias de JVM ejecutándose junto con recursos duplicados.
Si crea una aplicación que permite complementos de terceros, puede cargar esos complementos en un Dominio de aplicaciones separado para que su aplicación principal esté a salvo de un código desconocido.
ASP.NET también utiliza AppDomains por separado para cada aplicación web dentro de un proceso de trabajo único.
Veo 2 o 3 casos de uso principales para crear dominios de aplicación separados:
1) Aislamiento similar al proceso con bajo uso de recursos y sobrecarga. Por ejemplo, esto es lo que hace ASP.NET: hospeda cada sitio web en un dominio de aplicación separado. Si utilizaba diferentes subprocesos en el dominio de aplicación único, el código de diferentes sitios web podría interferir entre sí. Si alojara diferentes sitios web en diferentes procesos, usaría muchos recursos y también la comunicación entre procesos es relativamente difícil en comparación con la comunicación en proceso.
2) Ejecutar código que no es de confianza en un dominio de aplicación separado con permisos de seguridad particulares (esto está realmente relacionado con el primer motivo). Como ya se ha dicho, puede cargar plugins de terceros o dlls que no sean de confianza en dominios de aplicaciones separados.
3) Capacidad de descargar ensamblajes para reducir el uso innecesario de memoria. Desafortunadamente, no hay forma de descargar un ensamblaje desde un dominio de aplicación. Por lo tanto, si carga un ensamblaje grande en el dominio principal de la aplicación, la única forma de liberar la memoria correspondiente después de que el ensamblaje ya no sea necesario es cerrar su aplicación. Cargar ensamblajes en un dominio de aplicación separado y descargar ese dominio de aplicación cuando esos ensambles ya no son necesarios es una solución a este problema.