Nie rozumiem domen aplikacji

Question

. NET ma tę koncepcję Domen Aplikacji, która, jak rozumiem, może być używana do ładowania złożenia do pamięci. Zrobiłem kilka badań na temat domen aplikacji, a także udałem się do mojego lokalnego sklepu z książkami, aby uzyskać dodatkową wiedzę na ten temat, ale wydaje się to bardzo rzadkie.

Wszystko, co wiem, że mogę zrobić z Domenami aplikacji, to ładowanie złożeń w pamięci i mogę je rozładować, kiedy chcę.

Jakie są inne możliwości, o których wspomniałem w Domenach aplikacji? Czy wątki respektują granice domen aplikacji? Czy są jakieś wady związane z ładowaniem Zespołów w różnych Domenach Aplikacji innych niż Główne Domeny Aplikacji poza wydajnością komunikacji?

Linki do zasobów, które omawiają domeny aplikacji, również byłyby dobre. Sprawdziłem już MSDN, który nie ma na ten temat zbyt wiele informacji.

Answer 1

AppDomains najlepiej zwizualizowane jako proces bardzo lekki.

Na każdy proces .Net Process może być N AppDomains, ale ogólnie rzecz biorąc jest tylko jeden. Prawdziwą zaletą AppDomains jest zapewnienie granicy izolacji w ramach procesu. Obiekty mogą komunikować się ze sobą tylko przez granicę AppDomain poprzez zdalne lub serializowane.

Istnieje również możliwość uruchomienia 2 aplikacji na zupełnie różnych poziomach zabezpieczeń w ramach procesu. Może to pozwolić na uruchomienie głównej aplikacji w pełnym zaufaniu podczas uruchamiania niezaufanych wtyczek na znacznie niższym poziomie zaufania.

Trudno jest powiedzieć "tak" lub "nie", czy dany wątek respektuje daną AppDomain. Możliwe, że pojedynczy wątek znajduje się w N różnych AppDomains. Taka sytuacja jest możliwa, jeśli obiekt w jednej AppDomain wykonuje zdalne wywołanie obiektu w innym AppDomain. Wątek będzie musiał przejść między AppDomains, aby zakończyć.

Wadą AppDomains jest głównie złożoność. Remoting może zająć trochę czasu, aby zorientować się, a prawidłowe ustawienie AppDomain może być nietrywialnym procesem.

Możesz zajrzeć do dokumentacji MSDN na AppDomains. Trudno jest znaleźć samouczek, który je opisuje, ponieważ ma wiele złożonych funkcji. Zapewnia to dobry przegląd, który, jeśli nie odpowie bezpośrednio na twoje pytanie, przynajmniej wskaże cię we właściwym miejscu.

http://msdn.microsoft.com/en-us/library/cxk374d9.aspx

Ten dokument nie jest już utrzymywany proszę odnieść się do tego na zaktualizowanej wersji: https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

Answer 2

Niektóre rzeczy można zrobić z AppDomains:

• można go zamknąć bez zagraża stabilności twojego programu.
• Możesz załadować kod i przyznać mu mniej przywilejów niż własny proces (np. Twój proces działa w pełni zaufany, ale ładujesz kod w oddzielnym AppDomain, który nie może nawet utworzyć pliku na dysku.)
• Możesz obsłużyć nieobsługiwane wyjątki AppDomain bez konieczności zawieszania procesu.
• Itd.

Mówiąc najprościej, jest to granica bezpieczeństwa i prawie granica procesu. Jeśli chodzi o wydajność, wiele AppDomains w ramach procesu nie stanowi znacznego obciążenia. Uruchomienie oddzielnego procesu zamiast AppDomain jest znacznie bardziej kosztowne.

Answer 3

Odpowiedź JaredPar jest dobra, z tą różnicą, że nie odnotowuje wartości raison d'etre dla AppDomains - co oznacza, że ​​można WYBRAĆ Zgromadzenie tylko przez wyładowanie jego AppDomain. Jeśli jesteś długo działającym procesem systemu operacyjnego i spodziewasz się załadować , a następnie rozładować zespoły z dowolnego powodu, potrzebujesz AppDomain. Prototypowym przykładem jest ASP.NET, który ładuje zespoły kodu aplikacji na żądanie, a następnie może je później wyładować, gdy aplikacje nie są już aktywnie używane.

Kosztem, jaki zapłacisz za możliwość rozładowania, jest ta niezależność - musisz komunikować się przez granicę AppDomain, Nie można wykonać prostego wywołania metody. Musisz zarządzać cyklem życia aplikacji AppDomain. Itp

Jeśli wystarczy dynamicznie załadować zespoły i nie sądzę, musisz wyładować je ciągu życia jednego procesu to prawdopodobnie nie trzeba uruchamiać wiele AppDomains. Dobrym przykładem może tu być bogata aplikacja obsługująca model wtyczki, w której wyszukuje zespoły wtyczek w katalogu "etc" i ładuje je wszystkie. Jeśli jednak model wtyczki wymaga wyładowania wtyczek ... dobrze.

Istnieją niespotykane scenariusze. Przypuśćmy, że chcesz załadować dwie różne wersje Zgromadzenia w tym samym czasie. Możesz natrafić na pułapki, jeśli nie segregujesz ich z AppDomains. Ale to będzie dość rzadkie.

Głównym scenariuszem uzasadniającym istnienie AppDomains jest długotrwały proces, który musi umożliwiać rozładowanie złożeń.

Oczywiście aplikacje mogą polegać na procesie systemu operacyjnego, gdy chcemy zwolnić zespół. Innymi słowy, możesz mieć 3 lub 4 współpracujące ze sobą procesy, każdy z własnym zbiorem Zespołów, a gdy chcesz zwolnić zespół, po prostu zamknij proces, który go obsługuje. Ale AppDomain oferuje do tego lepszy mechanizm, bez konieczności zatrzymywania/uruchamiania procesu lub komunikatów między procesami, który jest jeszcze cięższy niż opisane powyżej komunikaty Cross-AppDomain. Mam na myśli to, że nadal działa zdalnie, ale jest wolniejszy i zmienia kontekst.