Leistungsstrafe bei Verwendung von Klassen in aspx und ascx Codebehinds

Question

Was ist die Leistungsstrafe für das Definieren von Klassen in einem aspx/ascx-Codebehind anstatt sie vorher in eine dll zu kompilieren? Ich weiß, dass dies keine bewährte Methode ist und dass es zahlreiche Probleme damit gibt (z.B. schwierig zu unit testen, Code ist nicht wiederverwendbar, usw.), aber es ist sehr praktisch, wenn man mit Klassen umgeht, die mehrmals am Tag geändert werden müssen, da diese Änderungen keinen Neustart der App erfordern (z.B. Änderungen in App_Code, Aktualisierung von dlls im bin-Verzeichnis).

Answer 1

"Keine." Die Codebehind-Klassen werden dynamisch in eine DLL kompiliert und diese DLL wird dann aufbewahrt. Also im Grunde genommen gibt es beim ersten Laden der Seite eine kurze Verzögerung, aber danach sollte die Geschwindigkeit genauso schnell sein wie bei vorab kompilierten Klassen.

Answer 2

Sie sollten nach dem ersten Kompilieren keine Leistungsprobleme feststellen. Es scheint, als ob Sie Geschäftslogik haben, die sich häufig ändert, und nicht unbedingt die Webseiten.

Answer 3

Die Entscheidung, ob dynamische Kompilierung oder kompilierte DLLs verwendet werden sollen, hängt wirklich davon ab, wie organisiert Ihr Freigabeprozess ist. Wenn Ihre Anwendung fest in DLLs kompiliert ist, können Sie erwarten, dass Sie auf Build-Fehler getestet haben und erwarten, dass die Dinge stabiler sind, wenn Sie veröffentlichen. Mit dynamischer Kompilierung haben Sie die Möglichkeit, .cs-Dateien im Handumdrehen auszutauschen (z. B. Drag & Drop, FTP). Das bedeutet, dass Sie möglicherweise agiler sind, aber Sie haben vielleicht nicht diesen zusätzlichen Schritt der Gewissheit, der Ihnen hilft zu wissen, dass Sie den Build intakt halten.

Answer 4

Nebenwirkungen - Sitzungsrücksetzungen

Aus persönlicher Erfahrung sind Benutzer viel eher bereit, sich über Sitzungsrücksetzungen aufgrund des Recycling des App-Domänen zu beschweren, als über geringfügige Leistungseinbußen. Wenn Sie also Ihre Änderungen von Code auf Daten verschieben und vollständig auf Code-Updates verzichten können, tun Sie es bitte. Dies wird die Leistung Ihrer Benutzer verbessern :)

Answer 5

Ich glaube nicht, dass es wirklich eine Leistungsstrafe gibt nach der initialen dynamischen Kompilierung (die beim ersten Aufruf der Seite stattfinden wird, bei der der Code-behind geändert wurde). Wie kam es dazu, dass Sie mehrmals täglich Klassen ändern mussten? Das wäre schrecklich!

BEARBEITEN: Ich sollte hinzufügen, dass dies Unit-Tests oder die Code-Wiederverwendbarkeit nicht beeinflussen sollte, wie Sie festgestellt haben. Es hindert Sie nichts daran, eine nicht vorab kompilierte Website aus Gründen der Wartbarkeit bereitzustellen, während Sie trotzdem in der Lage sind, Unit-Tests durchzuführen, kompilierte Assemblys für andere Projekte bereitzustellen (falls erforderlich) usw. während eines Check-ins/einer Build.

Wenn Sie jedoch kein Versionskontrollsystem verwenden und keinen automatisierten Build haben, dann gibt es ein ganz neues Problem. Unsere Teammitglieder haben früher CODE-Dateien direkt auf Produktionsservern bearbeitet. Zittern