Pénalité de performance lors de la mise en classes de classes aspx et ascx codebehinds

Question

Quelle est la pénalité liée aux performances lors de la définition de classes dans un code de code aspx/ascx plutôt que de les compiler dans une DLL au préalable? Je sais que ce n'est pas une bonne pratique et qu'il y a de nombreux problèmes avec cela (par exemple, difficile à tester, le code n'est pas réutilisable, etc.), mais cela est très pratique quand on a besoin de cours être modifié à la volée plusieurs fois par jour, car ces modifications ne nécessiteront aucune sorte de redémarrage de l'application (par exemple, App_Code change, mise à jour des DLL dans le dossier bin).

Answer 1

"Aucune". Les classes codebehind sont compilées dans une DLL à la volée, puis cette DLL est conservée. Donc, fondamentalement, la première fois que vous chargez la page, il y aura un court délai, mais après, la vitesse devrait être la même que pour les classes précompilées.

Answer 2

Je ne crois pas qu'il y ait vraiment une pénalité de performance après la compilation dynamique initiale (qui se produira lors du premier hit de la page dont le code-behind a été modifié). Comment avez-vous fini par devoir changer de cours plusieurs fois par jour? Cela serait nul!

EDIT: J'aurais dû ajouter que cela ne devrait pas affecter les tests unitaires ou la réutilisabilité du code comme vous l'avez dit. Rien ne vous empêche de déployer un site non pré-compilé à des fins de maintenabilité tout en pouvant exécuter des tests unitaires, déployer des assemblys compilés pour d'autres projets (si nécessaire), etc. lors d'un check-in/build. Cependant, si vous n'utilisez pas le contrôle de code source et que vous ne disposez pas d'une version automatisée, il y a un tout nouveau problème. Les membres de notre équipe éditaient les fichiers CODE directement sur les serveurs de production. shivers

Answer 3

Vous ne devriez voir aucun problème de performance après la compilation initiale. Il semble que vous ayez une logique métier qui change fréquemment, et pas nécessairement les pages Web.

Answer 4

Le choix d'utiliser la compilation dynamique ou les DLL compilées dépend vraiment de l'organisation de votre processus de publication. Si votre application est étroitement compilée dans des DLL, vous pouvez vous attendre à ce que vous ayez testé les erreurs de construction et à vous attendre à ce que les choses soient plus robustes lorsque vous publiez. Avec la compilation dynamique, vous avez la possibilité d'échanger des fichiers .cs à la volée (par exemple glisser & drop, ftp). Cela signifie que vous pouvez être plus agile, mais vous n'avez peut-être pas cette assurance supplémentaire qui vous aide à savoir que vous gardez la construction intacte.

Answer 5

dommages collatéraux - remet à zéro la session

Par expérience personnelle, les utilisateurs sont beaucoup plus susceptibles de se plaindre de la réinitialisation de la session provoquée par le recyclage App Domaine d'environ une légère baisse de performance. Donc, si vous pouvez déplacer vos modifications du code vers les données et éviter complètement les mises à jour de code, faites-le par tous les moyens. Cela permettra d'améliorer les performances de vos utilisateurs :)