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

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

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

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

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

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

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

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

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

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

Насколько я понимаю, AppDomain предназначены для того, чтобы предоставить объекту хостинга (ОС, БД, сервер и т. д.) Свободу запускать несколько приложений в одном экземпляре CLR или каждой программе в отдельности. Так что это проблема скорее для хоста, чем для разработчика приложения.

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

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

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

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

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

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

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

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