AjaxControlToolkit组合框替代大量项目
我有一个使用 ASP.NET 4.0 Web 应用程序的位置，该应用程序运行良好大约 2 年。我去现场进行升级，发现其中一个页面是空白的，IE 8 完全停止响应。经过调查，我发现页面上的一个组合框有超过 8000 个项目。该页面在 IE7、IE9、Firefox 和 Chrome 中加载良好。我查看了 Ajax Control Toolkit 站点上的文档，他们说我应该使用 Auto Complete Extender，因为我有如此多的记录。我认为它在任何浏览器中都不起作用只是时间问题。该设施使用 IE8，因此我目前让它们以兼容模式运行；然后我告诉他们开始删除不再需要的旧记录。然而，我需要开始研究替代品。自动完成扩展器的问题在于它不像组合框那样工作。有谁知道有什么好的方法吗？我需要将 DataSource 和 DataBinding 样式保留在代码隐藏中。此外，重新设计也不是一种选择。我需要该列表来包含任何给定设施的所有访客。
I have a location using our ASP.NET 4.0 web application which was running fine for about 2 years. I went out on site to do an upgrade and found that one of the pages would just be blank and IE 8 would completely stop responding. Upon investigation I found that one of the comboboxes on a page had over 8000 items. The page loaded fine in IE7, IE9, Firefox, and Chrome. I looked at the documentation at that Ajax Control Toolkit site and they say that I should be using the Auto Complete Extender since I have such a high number of records. I figure it is only a matter of time before it doesn't work in any browser. The facility uses IE8, so I currently have them running in compatibility mode; I then told them to start deleting old records that they don't need anymore. However, I need to begin working on a substitute. The problem with the Auto Complete Extender is that it doesn't work anything like the combobox. Does anyone know of a good approach? I need to keep the DataSource and DataBinding style in the code-behind. Also, redesign is not an option. I need that list to contain all Visitors for any given facility.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于 8000 个项目，我建议使用一个控件，该控件可以按需填充和过滤（而不是在 Page_Load 上），并且不会将所有项目保留到 ViewState。
不幸的是，按需填充和过滤不利于保持数据源和数据绑定风格的完整性。剩下的就是尝试使用带有 EnableViewState="false" 的控件，并通过一切可用的方法最小化页面大小，首先是使用压缩。在 IIS 中，启用动态压缩。我不认为这些步骤能够解决性能问题，但您应该从使用 YSlow 或其他工具分析页面大小开始。例如，如果页面具有可选元素（例如客户特定的组合框），请确保仅实际填充正在使用的元素。我曾经遇到过这样的情况：通过不填充未使用的控件并禁用它们的 ViewState，我能够将页面大小缩小一半以上。设置 Visible="false" 还不够。
至于替代方案，我使用了 Telerik RadCombobox 和 with类似的项目计数和性能问题。设置 EnableViewState="false" 显着提高了回发速度，但加载时间仍然不可接受。切换到按需加载有帮助，但引入了在没有 ViewState 的情况下保留选定状态的新问题。按需填充组合框意味着每次在 UI 中打开组合框时，都会在 ItemsRequested 事件中执行数据绑定。这与使用具有 AutoCompleteExtender 和页面方法的普通 TextBox 大致相同。您可能可以在此处重用大部分 Page_Load 时间数据绑定代码。
总的来说，我在 jQuery UI 自动完成 和 Ajax 请求方面获得了最佳体验，但这会涉及更多广泛的重新设计。
With 8000 items I would recommend a control that is both populated and filtered on demand (not on Page_Load), and doesn't persist all items to ViewState.
Unfortunately, populating and filtering on demand runs against keeping the DataSource and DataBinding style intact. What remains is trying to use the control with EnableViewState="false" and minimizing the page size by all means available, first and foremost by using compression. In IIS, enable dynamic compression. I don't think that these steps are going to solve the performance problem, but you should start with analyzing the page size with YSlow or other tools. For example, if the page has optional elements, like customer specific comboboxes, make sure that only those that are in use are actually populated. I have had situations where I've been able to more than half the page size by not populating the unused controls and disabling ViewState for them. Setting Visible="false" was not enough.
As for alternatives, I have used Telerik RadCombobox with with similar item counts and performance problems. Setting EnableViewState="false" improved postback speed significantly, but load times were still not acceptable. Switching to load on demand helped, but introduced new problems with persisting the selected state without ViewState. Populating the combobox on demand on means that databinding is performed in a ItemsRequested event, each time the combobox is opened in the UI. This is about the same as using an ordinary TextBox with AutoCompleteExtender and a page method. You probably could reuse most of the Page_Load time databinding code here.
Overall, I have had the best experience with jQuery UI autocomplete and Ajax requests, but this would involve a more extensive redesign.