2010-02-10 18 views

Antwort

4

Ein Vorteil ist die Unterstützung einer Plugin-Architektur.

Angenommen, Sie möchten z. B. einen Dienst schreiben, der verschiedene Arten von Aufgaben planmäßig ausführt. Was diese Aufgaben tun, ist nicht wirklich relevant für Ihren Kerndienst, der nur dazu da ist, sie zur richtigen Zeit anzustoßen. Und es ist mehr als wahrscheinlich, dass Sie Unterstützung hinzufügen möchten, um andere Arten von Aufgaben in der Zukunft zu erledigen (oder ein anderer Entwickler könnte dies gerne tun). In diesem Szenario können Sie durch die Implementierung eines Plug-In-Ansatzes dlls, die unabhängig vom Core-Service codiert werden können, in weitere (durch die Schnittstelle kompatible) DLLs einfügen. Das Hinzufügen neuer Unterstützung für eine neue Aufgabe erfordert keine neue Erstellung/Bereitstellung des gesamten Dienstes. Wenn sich eine bestimmte Aufgabe ändern muss, muss nur diese DLL erneut bereitgestellt und dann automatisch abgerufen werden.

Es erfordert auch andere Entwickler, sich nicht mit dem Dienst selbst zu beschäftigen, sie müssen nur wissen, welche Schnittstelle zu implementieren ist, damit sie abgeholt werden kann.

+0

Was ist, wenn Ihr System ein Nicht-Plugin-Architektur-System ist. Welche anderen Vorteile würden sie haben? – James

+0

Das einzige Mal, dass ich es getan habe, ist innerhalb einer Plugin-Architektur tbh. Ich kann mir keinen anderen Grund vorstellen, warum ich es sonst anders betrachten würde. Vielleicht eine Art von Sicherheits-Zweck - d. H. Nur DLLs laden, die die Funktionalität geben, auf die ein bestimmter Benutzer Zugriff hat. Aber ich bin mir nicht einmal sicher, ob das ein gültiger Ansatz wäre, nur andere Code-Möglichkeiten zu kontrollieren! – AdaTheDev

+0

Was ist mit Leistung? Ist es wichtig, dass Sie eine DLL geladen haben, obwohl Sie sie eigentlich nur selten verwenden würden? – James

1

Loading Shared Objects dynamisch ist der Mechanismus für Plugins ad hoc zu laufenden Anwendungen. Ohne Plugins müsste eine modulare Anwendung zur Laufzeit oder zur Kompilierzeit zusammengestellt werden (siehe Code von nginx).

1

Ihre Frage ist über C# /. NET, also in dieser Welt erfordert dynamische DLL-laden fortgeschrittene Programmierkenntnisse. Dies könnte alle potenziellen Vorteile des dynamischen DLL-Ladens ausgleichen. Sie müssten einfach viel "Low Level" -Code schreiben.

In C++/Win32 muss ich oft eine DLL dynamisch laden, wenn diese DLL eine neue API-Funktion hat, die auf älteren Betriebssystemen nicht verfügbar ist. In diesem Fall muss ich sicherstellen, dass diese API zur Laufzeit verfügbar ist. Ich kann nicht einfach eine Verknüpfung mit dieser DLL herstellen, da dies zu Fehlern beim Laden von Anwendungen auf älteren Betriebssystemen führt.

Wie bereits erwähnt, könnten Sie in einer pluginbasierten Umgebung auch einige Vorteile haben. In diesem Fall hätten Sie mehr Kontrolle über Ihre Ressourcen, wenn Sie DLLs dynamisch laden. Im Wesentlichen ist COM ein gutes Beispiel für dynamische DLL-Übergabe.

2

Wir verwenden diese Architektur für unsere Verarbeitungsanwendungen, um mit den Unterschieden umzugehen, die unsere verschiedenen Kunden benötigen. Jede DLL hat eine ähnliche Struktur und implementiert die gleiche Schnittstelle und Eingabemethode "Process()". Wir haben eine XML-Datei, die definiert, welche Klasse basierend auf dem Kunden geladen werden soll und ob es mehr Methoden neben dem Prozess gibt, die aufgerufen werden müssen. Performance sollte kein Problem sein, bis Ihre Transaktionsanzahl sehr hoch ist.

1

Wenn Sie nur die benötigten DLLs laden, sollte die Startupzeit der Anwendung schneller sein.

0

Ein weiterer Grund, DLLs dynamisch zu laden, ist Robustheit.

Es ist möglich, eine DLL in eine so genannte AppDomain zu laden. Eine App-Domäne ist im Grunde genommen ein Sandbox-Container, in den Sie Dinge einfügen können (entweder Teile von DLLs oder ganze EXEs), die isoliert, aber innerhalb Ihrer Anwendung ausgeführt werden.

Wenn Sie keinen in einer AppDomain enthaltenen Typ aufrufen, hat er keine Möglichkeit, mit Ihrer Anwendung zu interagieren.

Wenn Sie also eine dubiose DLL eines Drittanbieters haben oder eine DLL, für die Sie den Quellcode nicht haben, können Sie sie in eine AppDomain laden, um sie von Ihrem Hauptanwendungsablauf isoliert zu halten.

Das Endergebnis ist, dass, wenn die DLL von Drittanbietern einen Wobbly wirft, nur die Appdomain und nicht Ihre gesamte Anwendung betroffen ist.

Verwandte Themen