Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Bonn-to-code.net Die AppDomain Das unbekannte Wesen? 19.11.2013 Dr. Jochen Manns Website:http://www.jochen.jochen-manns.dehttp://www.jochen.jochen-manns.de.

Ähnliche Präsentationen


Präsentation zum Thema: "Bonn-to-code.net Die AppDomain Das unbekannte Wesen? 19.11.2013 Dr. Jochen Manns Website:http://www.jochen.jochen-manns.dehttp://www.jochen.jochen-manns.de."—  Präsentation transkript:

1 bonn-to-code.net Die AppDomain Das unbekannte Wesen? Dr. Jochen Manns Website:http://www.jochen.jochen-manns.dehttp://www.jochen.jochen-manns.de

2 bonn-to-code.net Agenda  Kleine Einführung  AppDomains und die Anwendung  Varianten von Marshalling  Marshalling in der Praxis  By Value  By Reference  It depends…

3 bonn-to-code.net Übersicht

4 bonn-to-code.net.NET und die AppDomain  Jeder Code läuft in einer AppDomain  Threads sind ein orthogonales Konzept  Mindestens eine AppDomain pro Prozess  Default AppDomain wird beim Starten angelegt  Weitere müssen explizit erzeugt werden  Im Normallfall unsichtbar  Nur die Default AppDomain  Keine Notwendigkeit, AppDomains zu kennen

5 bonn-to-code.net Warum benutzt man AppDomains?  Eine Art Prozess im Windows Prozess  In.NET hochgradig isoliert  Nativer Code kennt keine Grenzen  Eigene Sicherheitsregel  Vor allem Ausführungspfade für Bibliotheken  Erweiterungskonzepte / PlugIns  Sichere, abgeschirmte Umgebung der PlugIns  Kontrollierte Schnittstelle zum Host  Zeitweises Laden von Bibliotheken

6 bonn-to-code.net ASP.NET und IIS  Ein Prozess pro Application Pool  Eine AppDomain pro virtuellem Verzeichnis  Mehrere virtuelle Verzeichnisse pro Pool  Trotzdem vollständig isoliert (.NET)  ASP.NET Hosting  ApplicationHost Klasse  Volle ASP.NET Laufzeitumgebung  Web.Config, WebApi, MVC, ASPX, ASMX, …  Separate AppDomain für den Host

7 bonn-to-code.net Kommunikation

8 bonn-to-code.net Kommunikation und Marshalling  Isolation kontrolliert durchbrechen  Proxy / Stub Objekte  Proxy in der steuernden AppDomain (Host)  Stub in der untergeordnete AppDomain  Inter-AppDomain Methodenaufrufe  AppDomain Wechsel auf einem einzigen Thread  Indirekte Aufrufe kosten Zeit  Was ist aber mit Daten / Objekten?  Marshalling in zwei Varianten

9 bonn-to-code.net Marshal By Value  Vollständige Übertragung  Keine Kommunikation über die Daten  Hohe Unabhängigkeit der AppDomains  Datenaustausch, evtl. umfangreich  [Serializable]  Binäre Variante  Berücksichtigt alle.NET Fields  [NonSerialized]  Zwingend für alle referenzierten Objekte

10 bonn-to-code.net Marshal By Reference  Proxy Referenz auf einen Stub  Keine Datenübertragung  Zugriff erfordern erneuten AppDomain Wechsel  Jede Codeausführung (auch der Abruf eines.NET Fields) erfolgt in der AppDomain, in der das Objekt erzeugt wurde  Im By Value Fall wird Code immer in der AppDomain des Aufrufers ausgeführt  Ableiten von MarshalByRefObject

11 bonn-to-code.net Böse Falle Garbage Collection  Ein Proxy ist keine starke Referenz  Der Stub muss sich vor Freigabe schützen  InitializeLifetimeService  Ansonsten ist der Proxy irgendwann kaputt

12 bonn-to-code.net ASP.NET Hosting

13 bonn-to-code.net WebApi Hosting in einem Dienst  Datenverwaltung im Dienst  Datenbank  Steuerungslogik  Kontrollierte Laufzeitumgebung  Remote Schnittstelle für Clients  WCF  WebApi Self Hosting  ASP.NET Hosting  Für REST, aber auch ASPX, ASMX, …  Betriebssicherheit durch Isolation

14 bonn-to-code.net Zugriff auf die Dienst AppDomain  ASP.HET Hosting über Proxy / Stub  Dienst kann auf ASP.NET Laufzeit zugreifen  Sequenz immer ähnlich m_Runtime = (IASPNETProxy) ApplicationHost.CreateApplicationHost( typeof( ASPNETProxy), … ); m_Runtime.SetServer( m_Server );  Dienstobjekt in ASP.NET verfügbar machen  By Reference  Stub lebt im Dienst  Proxy kann von ASP.NET angesprochen werden

15 bonn-to-code.net Marshalling

16 bonn-to-code.net REST via Marshal By Reference [DataContract] public class ClientResponse { [DataMember] public string Data { get; set; } } var response = new ClientResponse { Data = proxy.Analyse( 12 ) }; Die Antwort an den Client wird in der ASP.NET AppDomain erstellt. Jeder Aufruf an den Dienstproxy muss die AppDomain Grenze überschreiten. Alle Objekte müssen eine Überschreitung zulassen: By Value, wie alle einfachen.NET Klassen By Reference, üblicherweise eigene Klassen Wilder Zugriff führt zu Fehlermeldungen, gute Kontrolle! Die Ausführungsgeschwindigkeit kann leiden Besondere Vorsicht bei Listen von Objekten Viele Einzelzugriffe auf.NET Fields & Properties evtl. problematisch public interface IServiceProxy { string Analyse( int depth ); }

17 bonn-to-code.net REST via Marshal By Value [Serializable] public class ServiceResponse { public string Data { get; set; } } var serviceResponse = proxy. Analyse( 12 ); var response = new ClientResponse { Data = serviceResponse.Data }; Die AppDomain des Dienstes bereitet alles vor Die Bearbeitung findet vollständig dort statt In der ASP.NET AppDomain wird noch einmal umkopiert Die Dienst AppDomain kann natürlich auch direkt das Ergebnis erzeugen Dann muss dieses aber auch By Value sein [DataContract, Serializable] public class ClientResponse { [DataMember] public string Data { get; set; } } public interface IServiceProxy { ServiceResponse Analyse( int depth ); } public interface IServiceProxy { ClientResponse Analyse( int depth ); } var response = proxy.Analyse( 12 );

18 bonn-to-code.net Code Abhängigkeiten using System; using System.Collections.Generic; using Sample.ClientNamespace; namespace Sample.ServiceNamespace { public class ServiceItem { public Service Service { get; private set; } public string Data { get; private set; } public ClientItem ToClient() { return new ClientItem { Data = Data }; } public class Service : MarshalByRefObject { private readonly List m_items = new List (); public ClientItem ToClient( int index ) { return m_items[index].ToClient(); } using System; using System.Runtime.Serialization; using Sample.ServiceNamespace; namespace Sample.ClientNamespace { [DataContract, Serializable] public class ClientItem { public string Data { get; set; } } public class TheController { public ClientItem GetItem( int index ) { return ASPNETRuntime.ServiceProxy.ToClient( index ); }

19 bonn-to-code.net Entkoppeln using System; using System.Collections.Generic; namespace Sample.ServiceNamespace { public class ServiceItem { public Service Service { get; private set; } public string Data { get; private set; } } public class Service : MarshalByRefObject { private readonly List m_items = new List (); public TClientType ToClient ( int index, Func factory ) { return factory( m_items[index] ); } using System; using System.Runtime.Serialization; using Sample.ServiceNamespace; namespace Sample.ClientNamespace { public class TheController { public ClientItem GetItem( int index ) { return ASPNETRuntime.ServiceProxy.ToClient( index, ClientItem.FromService ); } [DataContract, Serializable] public class ClientItem { public string Data { get; set; } public static ClientItem FromService( ServiceItem item ) { return new ClientItem { Data = item.Data }; } Die statische Methode wird in der AppDomain des Dienstes ausgeführt!

20 bonn-to-code.net Marshal By Value nach Bedarf  Mehrere By Value Varianten nutzen  Je nach Kontext verschiedene Inhalte  Pro REST Controller oder gar pro Methode  Gezielt mischen  By Reference für äußere Objekte  By Value für Detailobjekte  Querreferenzen können verloren gehen  Querreferenzen lassen Datenmenge explodieren

21 bonn-to-code.net Zusammenfassung  AppDomains sind isolierte Bereiche  Innerhalb eines Windows Prozesses  Methoden werden über Proxy Klassen aufgerufen  Daten werden By Value oder By Reference ausgetauscht  Beide Varianten haben Vor- und Nachteile  Hybride führen oft zur besten Lösung  Generische Methoden zur Entkoppelung


Herunterladen ppt "Bonn-to-code.net Die AppDomain Das unbekannte Wesen? 19.11.2013 Dr. Jochen Manns Website:http://www.jochen.jochen-manns.dehttp://www.jochen.jochen-manns.de."

Ähnliche Präsentationen


Google-Anzeigen