Ist es eine schlechte Übung, eine große Anzahl von Skripten als eingebettete Ressource in ein Projekt aufzunehmen?

Question

Ich entwerfe ein Visual Studio-Projekt, das eine potenziell große Anzahl (bis zu ~ 300) von Skriptdateien verschiedener Typen verwenden wird. Diese Dateien werden nicht mit anderen Projekten geteilt, d. H. Sie sind exklusiv für das Projekt. Gibt es ein gutes Argument gegen alle diese Dateien als eingebettete Ressource (indem Sie ihre Build-Aktion festlegen) und dann Assembly.GetManifestResourceStream() verwenden, um sie zur Laufzeit abrufen? Oder wäre dies ein Missbrauch von eingebetteten Ressourcen, und stattdessen sollte ein Dateisystemverzeichnis verwendet werden, das diese Ressourcen als Dateien enthält?

Die Vorteile von Embedded-Ressourcen zu sein scheinen:

• die erzeugte Baugruppe (über fehlende Skriptdateien oder ungültige Pfade sorgen, ohne dass einzelne Datei Deployment) ist einfach zu teilen und einsetzen;
• Isolation und Bequemlichkeit: auf alle Ressourcen kann innerhalb des VS-Projekts zugegriffen werden.

Die Argumente gegen diesen Ansatz sind in der Regel:

• Sie nicht die Ressourcen ohne erneute Kompilierung und Umschichtung der Baugruppe ändern können. Aber selbst für ein Projekt mit vielen textbasierten Ressourcen ist die resultierende Assembly eher klein und ebenso einfach wie das Überschreiben, z. Eine einzelne Dateisystem-Skriptdatei wäre. Und theoretisch sollte es möglich sein, nur den geänderten Teil der Assembly zu ersetzen (daher kleineres Update), aber mir ist nicht bekannt, ob solche existierenden Diff/Merge-Tools existieren.
• Die produzierte DLL wird größer sein, eventuell vielleicht signifikant; Andererseits ist die Gesamtgröße des zu implementierenden Programms dieselbe, wenn Sie eine schlanke Assembly ohne eingebettete Ressourcen erstellen und die Ressourcen separat in einem Verzeichnis bereitstellen.

Gibt es andere Überlegungen? Gibt es allgemein einen Grund dafür, dass Projektressourcen - unabhängig davon, was sie sind - nicht als eingebettete Ressourcen enthalten sein sollten, abgesehen von der erforderlichen Neukompilierung der Baugruppe im Falle einer Änderung?

Answer 1

Ich kann Ihnen einige Einblicke aus einer komplexen Umgebungsperspektive geben.

Wenn Ihre Anwendung für Ihre Organisation nahe oder kritisch ist und Sie die Reaktionszeit für Vorfälle minimieren müssen, ist es natürlich besser, alle Skripts als separate Dateien zu haben. Auch wenn es sehr einfach ist, Ihre Assembly neu zu kompilieren, erfordert eine Hotfix-Version in einer strukturierten Unternehmensumgebung normalerweise eine Reihe von Durchläufen, um selbst im Notfall durchzudringen. Außerdem erfordert dies eine Entwickler-Person, während die Support-Person gut genug sein sollte, um eine Skript-Datei zu ändern.

Eine andere Überlegung könnte sein, wenn (zumindest einige) Skripts beim Streamen von Ressourcen nicht ordnungsgemäß ausgeführt werden. Sie benötigen möglicherweise einen Platz zum Schreiben von Zwischen- oder Ergebnisdaten. Es kann auch einige Abhängigkeiten zwischen Skripten geben (eine ruft eine andere auf etc.))

Ein weiterer Faktor ist, dass Ressourcen getrennt zu haben, ermöglicht eine schnelle Überprüfung, wenn Sie keinen Zugriff auf die Projektquelle haben. Dies fügt Ihrer Anwendung Transparenz hinzu (was wünschenswert sein kann oder nicht). Es kann auch nützlich sein, um zu bestimmen, was mit Ihrer Anwendung passiert, falls Probleme auftreten und möglicherweise eine schnelle Änderung/Korrektur vornehmen (ähnlich wie bei meinem ersten Punkt).

Generell würde ich sagen, es hängt von Ihren Anforderungen ab. Wenn Sie häufige Änderungen an Ihren Skripten (oder anderen nicht kompilierbaren Ressourcen) vornehmen müssen, ist es viel besser, sie getrennt zu haben. Wenn sie sich nicht zu oft ändern und eine ordentliche, einfache und kompakte Dateistruktur haben möchten, ist die Einbettung eine gute Wahl.

Answer 2

Wenn es sich um ein Web-Projekt handelt, das Sie nur auf Ihrem eigenen Host verwenden, ist es besser, es nicht als eingebettete Ressourcen, sondern als normale Dateien zu verwenden. (Sie müssen das Projekt nur einmal installieren, aber es wird leicht, kleine Updates zu tun)

Wenn Sie eine DLL erstellen möchten, die in anderen Projekten wiederverwendbar sein kann, dann ist es besser, eingebettete Ressourcen zu verwenden - wenn Sie Aktualisieren Sie, Sie können nur eine DLL in jedem Projekt aktualisieren.