Вопрос

Меня постоянно спрашивают о доменах приложений в интервью, и Я знаю основы:

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

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

Ответы:

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

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

Это было полезно?

Решение

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

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

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top