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