Asp.net 在aspx和ASCXCodeBehinds中放置类的性能损失

在aspx/ASCXCodeBehind中定义类而不是事先将它们编译到dll中，性能会受到什么影响？我知道这不是一个最佳实践，并且存在许多问题（例如，难以进行单元测试、代码不可重用等），但当您处理需要每天动态修改多次的类时，它确实非常有用，因为这些修改不需要任何类型的应用程序重启（例如，应用程序代码更改、更新bin文件夹中的DLL）。

“无。”codebehind类被动态编译成DLL，然后该DLL被保留。因此，基本上第一次加载页面时会有一个短暂的延迟，但之后的速度应该与预编译类相同。

我不相信在初始动态编译后会有性能损失（这将发生在代码隐藏被修改的页面的第一次点击时）。你怎么会一天更改几次类呢？那太糟糕了

编辑： 我应该补充一点，这不应该像您所说的那样影响单元测试或代码的可重用性。在签入/构建期间，没有任何东西可以阻止您出于可维护性目的部署未预编译的站点，同时仍然能够运行单元测试，为其他项目部署编译的程序集（如果需要），等等

---

但是，如果您没有使用源代码管理，也没有自动生成，那么就出现了一个全新的问题。我们的团队成员过去常常直接在生产服务器上编辑代码文件。shivers

在初始编译之后，您应该看不到任何性能问题。听起来您的业务逻辑正在频繁更改，而不是n必要的是网页。

使用动态编译还是编译DLL的选择实际上与发布过程的组织方式有关。如果应用程序被严格编译为DLL，那么您可以预期，您已经测试了生成错误，并期望在发布时更加稳定。使用动态编译，您可以能够动态交换.cs文件（例如拖放、ftp）。这意味着您可能更加灵活，但您可能没有额外的保证步骤来帮助您确保构建完好无损。

附带损害-会话重置

---

从个人经验来看，用户更可能抱怨应用程序域回收导致的会话重置，而不是轻微的性能损失。因此，如果您可以将更改从代码转换为数据并完全避免代码更新，请务必这样做。这将提高用户的性能：）

我经常在我们的生产网站上遇到这样的情况，一些客户会提出一些奇怪的要求，要求在一天结束前“必须”到位……再次阅读我的帖子，我说在你第一次加载页面时会有性能损失。不过，之后它被编译，你就没事了。