在aspx / ascx代码隐藏中定义类而不是事先将它们编译成dll会有什么性能损失？我知道这不是最佳实践，并且存在许多问题（例如难以进行单元测试，代码不可重复使用等），但是当您处理需要的类时，它确实非常方便因为这些修改不需要任何类型的应用程序重启（例如App_Code更改，更新bin文件夹中的dll），所以每天要动态修改几次。
答案 0 :(得分：8)
“无”。代码隐藏类被动态编译成DLL，然后保留该DLL。因此，基本上第一次加载页面时会有一个短暂的延迟，但之后速度应该与预编译类相同。
答案 1 :(得分：1)
初始编译后，您应该看不到任何性能问题。听起来好像你的业务逻辑经常变化，而不一定是网页。
答案 2 :(得分：1)
是否使用动态编译或编译的DLL的选择实际上与您的发布过程的组织方式有关。如果您的应用程序被紧密编译到DLL中，那么您已经测试了构建错误并期望在发布时更加坚固。通过动态编译，您可以即时交换.cs文件（例如，拖放，ftp）。这意味着您可能更敏捷，但您可能没有额外的保证步骤，可以帮助您了解您保持构建完整。
答案 3 :(得分：1)
附带损害 - 会话重置
根据个人经验，用户更有可能抱怨App Domain回收引起的会话重置，而不是轻微的性能损失。因此，如果您可以将更改从代码转移到数据并完全避免代码更新，请务必执行此操作。这将改善用户的表现：）
答案 4 :(得分：0)
我不相信在初始动态编译之后确实存在性能损失（这将在首次点击其代码隐藏被修改的页面时发生）。您是如何最终每天多次改变课程的？那会很糟糕！
修改 我应该补充一点，这不应该像你所说的那样影响单元测试或代码可重用性。没有什么可以阻止您部署非预编译站点以实现可维护性，同时仍然能够在签入/构建期间运行单元测试，为其他项目（如果需要）部署已编译的程序集等。
但是，如果您没有使用源代码管理并且没有自动构建，那么就会出现一个全新的问题。我们的团队成员曾经在生产服务器上直接编辑CODE文件。 颤抖