在aspx / ascx代码背后定义类而不是事先将其编译为dll会带来什么性能损失？我知道这不是最佳实践，并且存在很多问题(例如，难以进行单元测试，代码不可重用等)，但是当我们处理需要处理的类时，它确实非常方便每天需要进行几次动态修改，因为这些修改无需重新启动任何应用程序(例如，更改App_Code，更新bin文件夹中的dll)。

解决方案

"没有。"隐藏代码的类被动态地编译为DLL，然后将该DLL保留下来。因此，基本上，第一次加载页面时会出现短暂的延迟，但是之后的速度应与预编译类的速度相同。

我不相信在最初的动态编译之后(这将在修改了其背后代码的页面的第一次点击时发生)确实确实对性能造成了影响。我们怎么最终一天不得不换几次班呢？那太烂了！

编辑：
我应该补充一点，这不会影响单元测试或者我们所说的代码可重用性。没有什么可以阻止我们出于可维护性目的而部署非预编译站点的，同时仍然能够运行单元测试，为其他项目(如果需要)部署已编译的程序集，等等。

但是，如果我们不使用源代码控制并且没有自动构建，那么就会出现一个全新的问题。我们的团队成员曾经直接在生产服务器上编辑CODE文件。颤抖

初始编译后，我们应该不会看到任何性能问题。听起来好像业务逻辑经常变化，而网页不一定变化。

是否使用动态编译或者已编译的DLL的选择实际上与发布过程的组织方式有关。如果应用程序被紧密地编译到DLL中，则我们可以期望我们已经测试过构建错误，并且发布时会更加坚固。使用动态编译功能，我们可以即时交换.cs文件(例如，拖放，ftp)。这意味着我们可能更加敏捷，但是我们可能没有额外的保证步骤，可以知道保持构建完整。

附带伤害会话重置

从个人经验来看，用户抱怨由App Domain回收引起的会话重置的可能性要大得多，而不是对性能的轻微影响。因此，如果我们可以将更改从代码转移到数据，并且完全避免代码更新，则一定要这样做。这将提高用户的性能：)