Хороший пример использования AppDomain

Я все время спрашиваю об AppDomains в интервью, и Я знаю основы:

они являются уровнем изоляции в приложении (что отличает их от приложений)
у них могут быть потоки (что отличает их от потоков)
исключения в одном приложении не влияют на другие
приложения не могут получить доступ друг к другу.
каждый appdomain может иметь разную безопасность

Я все еще не понимаю, что делает их необходимыми. Я ищу подходящее конкретное обстоятельство, если вы его используете.

Ответы:

Неверный код
- Основное приложение защищено
  Непринужденным/сторонним плагинам запрещается повреждать разделяемую память и несанкционированный доступ к реестру или жесткому диску путем изоляции в отдельном appdomain с ограничениями безопасности, защищая приложение или сервер. например Код компонента хостинга ASP.NET и SQL Server
Надежный код
- Стабильность
  Приложение сегментировано в безопасные, независимые функции/функциональность
- Архитектурная гибкость
  Свобода запуска нескольких приложений в одном экземпляре CLR или в каждой программе.

Что-нибудь еще?

Ответ 1

Вероятно, наиболее распространенным является загрузка сборок, содержащих код плагина от ненадежных сторон. Код работает в своем собственном AppDomain, изолируя приложение.

Также невозможно выгрузить определенную сборку, но вы можете выгрузить домены приложений.

Для полного изложения у Криса Брамма была большая запись в блоге об этом:

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

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

Ответ 2

Еще одно преимущество AppDomains (как вы упомянули в своем вопросе) - это код, который вы загружаете в него, может работать с разными разрешениями безопасности. Например, я написал приложение, динамически загружаемое DLL. Я был инструктором, и это были студенческие DLL, которые я загружал. Я не хотел, чтобы какой-то недовольный студент уничтожал мой жесткий диск или искажал мой реестр, поэтому я загрузил код из своих DLL в отдельный AppDomain, у которого не было прав доступа к файлам или разрешений для редактирования реестра или даже разрешений для отображения новых окон (на самом деле у него были только разрешения на выполнение).

Ответ 3

Я думаю, что основной мотивацией для AppDomains является то, что разработчикам CLR нужен способ изолировать управляемый код без ущерба для производительности нескольких процессов Windows. Если бы CLR была первоначально реализована поверх UNIX (где создание нескольких процессов значительно дешевле), AppDomains, возможно, никогда не были изобретены.

Кроме того, хотя управляемые архитектуры подключаемых модулей в сторонних приложениях, безусловно, являются хорошим использованием AppDomains, большая причина, по которой они существуют, - это известные хосты, такие как SQL Server 2005 и ASP.NET. Например, хостинг-провайдер ASP.NET может предложить решение для общедоступного хостинга, которое поддерживает несколько сайтов от нескольких клиентов, все в одном и том же поле, работающем под одним процессом Windows.

Ответ 4

Если вы создаете приложение, которое позволяет подключаемые модули сторонних производителей, вы можете загрузить эти плагины в отдельный AppDomain, чтобы ваше основное приложение было безопасным от неизвестного кода.

ASP.NET также использует отдельные AppDomains для каждого веб-приложения в рамках одного рабочего процесса.

Ответ 5

Домены приложений отлично подходят для стабильности приложений.

Благодаря тому, что ваше приложение состоит из центрального процесса, который затем генерирует "функции" в отдельных областях приложения, вы можете предотвратить глобальный сбой, если один из них ошибочно работает.

Ответ 6

Как я понимаю, AppDomain предназначен для того, чтобы позволить объекту хостинга (OS, DB, Server и т.д.) свободу запуска нескольких приложений в одном экземпляре CLR или каждой программе самостоятельно. Таким образом, это проблема для хоста, а не для разработчика приложений.

Это выгодно отличается от Java, где у вас всегда есть 1 JVM для каждого приложения, что часто приводит к тому, что многие экземпляры JVM работают бок о бок с дублированными ресурсами.

Ответ 7

Я вижу 2 или 3 основных варианта использования отдельных доменов приложений:

1) Технологическая изоляция с низким использованием ресурсов и накладными расходами. Например, это то, что делает ASP.NET - он размещает каждый веб-сайт в отдельном домене приложения. Если он использовал разные потоки в одном домене приложения, код разных веб-сайтов мог бы мешать друг другу. Если он размещал разные веб-сайты в разных процессах - он использовал бы много ресурсов, а также межпроцессное общение относительно сложно по сравнению с обработкой inprocess.

2) Выполнение ненадежного кода в отдельном домене приложения с определенными разрешениями безопасности (это фактически связано с первой причиной). Как уже говорили люди, вы можете загружать сторонние плагины или ненадежные dll в отдельные области приложений.

3) Возможность разгружать сборки, чтобы уменьшить ненужное использование памяти. К сожалению, нет способа выгрузить сборку из домена приложения. Поэтому, если вы загружаете какую-то большую сборку в свой основной домен приложения, единственный способ освободить соответствующую память после этой сборки больше не нужен, это закрыть приложение. Загрузка сборок в отдельный домен приложения и выгрузка этого домена приложения, когда эти сборки больше не нужны, является решением этой проблемы.