Ich habe vor kurzem damit begonnen, JavaScript- und CSS-Dateien in unsere gemeinsame Bibliotheks-DLLs einzubetten, um Bereitstellung und Versionierung deutlich zu vereinfachen. Ich frage mich nur, ob es einen Grund gibt, dies auch bei einer Webanwendung zu tun, oder ob es immer am besten ist, sie einfach als normale Dateien in der Webanwendung zu belassen und eingebettete Ressourcen nur für gemeinsam genutzte Komponenten zu verwenden?
Gäbe es einen Vorteil, sie einzubetten?
Ich musste diese Entscheidung einmal treffen. Der Grund, warum ich meine JavaScript/CSS-Ressourcen in meine DLL eingebettet habe, war, um eine Manipulation dieser Dateien (durch neugierige Endbenutzer, die meine Webanwendung gekauft haben) zu verhindern, sobald die Anwendung bereitgestellt ist.
Ich zweifle an Easements Kommentar zur Art und Weise, wie Browser JavaScript-Dateien herunterladen. Ich bin ziemlich sicher, dass die eingebetteten JavaScript/CSS-Dateien von ASP.NET vorübergehend neu erstellt werden, bevor die Seite an den Browser gesendet wird, damit der Browser sie herunterladen und verwenden kann. Ich bin neugierig darauf und werde meine eigenen Tests durchführen. Ich werde dich darüber informieren, wie es läuft....
-Frinny
Natürlich könnte jeder, der wusste, was er tat, den Assembly Reflector verwenden und den JS oder CSS extrahieren. Aber das wäre eine Menge Arbeit, viel mehr als einfach etwas wie FireBug zu verwenden, um an diese Informationen zu gelangen. Ein normaler Endbenutzer wird sich wahrscheinlich nicht die Mühe machen, nur um mit den Ressourcen herumzuspielen. Jemand, der an dieser Art von Dingen interessiert ist, wird wahrscheinlich ein bösartiger Benutzer sein, nicht der Endbenutzer. Sie haben wahrscheinlich viele andere Probleme in Bezug auf Sicherheit, wenn ein Benutzer ein Tool wie den Assembly Reflector in Ihrer DLL verwenden kann, denn zu diesem Zeitpunkt wurde Ihr Server bereits kompromittiert. Sicherheit war nicht der Faktor in meiner Entscheidung, die Ressourcen einzubetten.
Der Zweck bestand darin, Benutzer davon abzuhalten, etwas Dummes mit diesen Ressourcen zu machen, z.B. sie zu löschen, weil sie denken, dass sie nicht benötigt werden oder anderweitig mit ihnen herumzuspielen.
Es ist auch viel einfacher, die Anwendung für Bereitstellungszwecke zu paketieren, da weniger Dateien beteiligt sind.
Es stimmt, dass die DLL (Klassenbibliothek), die von den Seiten verwendet wird, größer ist, aber das macht die Seiten nicht größer. ASP.NET generiert den Inhalt, der an den Client (den Browser) gesendet werden muss. Es wird nicht mehr Inhalt an den Client gesendet, als für das Funktionieren der Seite erforderlich ist. Ich sehe nicht, wie die Klassenbibliothek, die diese Seiten bedient, sich auf die Größe der zwischen Client und Server gesendeten Daten auswirken wird.
Allerdings hat Rjlopes einen Punkt, es könnte wahr sein, dass der Browser nicht in der Lage ist, eingebettete JavaScript/CSS-Ressourcen zu zwischenspeichern. Ich werde das überprüfen müssen, aber ich vermute, dass Rjlopes richtig liegt: Die JavaScript/CSS-Dateien müssen jedes Mal neu heruntergeladen werden, wenn ein vollständiger Seiten-Rückübertragungsanforderung an den Server erfolgt. Wenn sich dies als wahr herausstellt, sollte dieser Leistungseinbruch ein Faktor in Ihrer Entscheidung sein.
Ich habe den Leistungsunterschied zwischen der Verwendung von eingebetteten Ressourcen, Ressourcen und Einzeldateien immer noch nicht testen können, weil ich mit meinen eigenen Unternehmungen beschäftigt war. Hoffentlich werde ich heute später dazu kommen, denn ich bin sehr neugierig darauf und auf den Punkt des Browser-Cachings, den Rjlopes angesprochen hat.
Ich interessiere mich sehr für das Cache-Problem. Ich kann mir nicht vorstellen, dass sie keine konsistenten URLs verwenden würden, um dem Browser zu ermöglichen, die Datei zu zwischenspeichern.
Eingebettete JS-Dateien, die über einen ScriptManager gerendert werden, werden tatsächlich zwischengespeichert und verwenden konsistente URLs in der gesamten Anwendung. Wir verwenden es sehr erfolgreich auf einigen Kundenseiten.
Vielen Dank für das Update, Zhaph. Wissen Sie zufällig, ob dasselbe auch für die Page.ClientScript.GetWebResourceUrl Methode gilt?
Grund für die Einbettung: Browser laden JavaScript-Dateien nicht parallel herunter. Es besteht eine Sperrbedingung, bis die Datei heruntergeladen ist.
Grund gegen die Einbettung: Möglicherweise benötigen Sie nicht den gesamten JavaScript-Code. Sie könnten also unnötig Bandbreite/Verarbeitung erhöhen.
Cuzillion ( stevesouders.com/cuzillion ) kann Ihnen zeigen, wie jede Inline-/eingebettete Auswahl und Platzierung auf der Seite die Gesamt-Ladezeiten der Seite beeinflussen kann.
@Ermäßigung, das ist eine interessante Seite, aber es scheint ein wenig konstruiert zu sein. Durch das Hinzufügen eines externen Stylesheets wird angezeigt, dass es eine 2-Sekunden-Verzögerung hinzufügen wird, was willkürlich erscheint. Und es scheint nicht auf die Idee der eingebetteten Ressourcen einzugehen.
Einige Browser laden tatsächlich parallel ab, oder? Oder zumindest denke ich, dass du Firefox instruieren kannst, dies zu tun. Wenn du sie einbettst, hat es dann nur einen Link, egal wie viele Dateien du eingebettet hast? Falls nicht, würde ich nicht denken, dass das einen großen Unterschied macht.
Ich musste diese Entscheidung einmal treffen. Der Grund, warum ich mich entschieden habe, meine JavaScript/CSS-Ressourcen in meine DLL einzubetten, war, um das Manipulieren dieser Dateien (durch neugierige Endbenutzer, die meine Webanwendung gekauft haben) nach Bereitstellung der Anwendung zu verhindern. Argumente gegen das Einbetten: Sie benötigen möglicherweise nicht den gesamten JavaScript-Code. Dadurch könnten Sie unnötig die Bandbreite/Verarbeitung erhöhen.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
0 Stimmen
Bitte sehen Sie hier für eine Lösung. Ich hoffe, dass diese Lösung Ihnen hilft.