ASP.Net过度使用用户控件

dav*_*eps 7 architecture asp.net performance user-controls trace

我正在研究一个在每个页面上广泛使用用户控件的asp.net Web应用程序.大多数页面包含大约10-20个用户控件.用户控件似乎是业务对象的可视化表示(如果这是有意义的),尽管具有更精细的粒度,例如选项卡控件的每个选项卡,其内容在用户控件中.该项目本身有200多个用户控件(ascx文件).

应用程序的性能非常差(我正在研究的原因).每个事件(例如点击或下拉选择等)都需要大约5秒的时间来加载页面(在Visual Studio中为10秒).该应用程序没有使用Ajax.

跟踪很痛苦,因为aspx页面本身在代码隐藏中没有代码,因为用户控件会查看所有这些代码,因此跟踪单个页面需要该页面上所有用户控件中的跟踪语句.

我实际上认为让每个用户控件都能看到它的业务代码并且可以重复使用是一个明智的想法,但是过度使用用户控件会导致性能下降吗?这看起来像是由具有强大WinForms背景的人编写的asp.net应用程序的结构吗?

EDIT
认为我应该补充一点,我不是在质疑用户控件的使用(甚至数量),而只是在页面上有这么多东西(例如每个用户控件连接到数据库)都会导致性能问题......例如,如果只有一个用户控制回发做某事,那么所有其他用户的处理,有些是可见的,有些则不是...... @ David McEwing提到他有40个优化的用户控件执行等,但如果开发人员是基于WinForms或"不熟悉asp.net",那么他们如何确保每个人都得到优化......

EDIT2
获取sql语句跟踪后,对于每个事件,每个页面调用执行相同的数据调用5-6次,因为不同的用户控件需要通常不存储的数据,例如选项卡中的每个用户控件(如上所述)从数据库中填充一个对象的同一个调用...我真的不是在这里指责用户控制是问题(我应该删除问题吗?),因为很明显问题不是用户控件,而是使用它们这个特殊情况......我认为这是过分的!

Rex*_*x M 10

仅10-20(甚至数百)个用户控制就是微不足道的.控件本身的存在以及封装的想法绝对不是您问题的根源.

如果没有实际分析应用程序当然是不可能准确地说出问题是什么,但根据我的经验,我可以这样说:

更有可能的是每个用户控件内部的业务逻辑的具体实现很差.由于回发只需要您描述,每个控件可能会回顾您的DAL,以获取每个请求的数据.这可以通过两件事来缓解:

  • 确保用户控件在首次加载时缓存所有数据,除非明确指示(通常来自较低级别服务的事件),否则永远不会重新加载它们
  • 确保控件都使用一组可以重用数据的公共服务.例如,如果两个控件需要访问客户列表,并且它们在同一请求会话的上下文中执行,那么应该只需要一个客户列表查找.


小智 5

我将坚定地站在人们的阵营中,这表明应该在页面上使用的许多用户控件没有硬性限制。听起来像是在整个应用程序范围内进行了跟踪,而不是页面级跟踪。很有可能是其中一些控件引起了问题。哎呀,它可能是引起所有麻烦的单个控件。但是,由于不可能对“平均”(如果有这种事情)用户控制所占用的资源使用水平做出任何假设,因此同样不可能提出限制。否则,我们可以对类的成员数或数据库的存储过程数提出类似的限制。

现在,如果我们要谈论的是20个复杂的用户控件,每个控件每次刷新都检索自己的数据,并且每个控件都带有一堆子控件(无论是否需要使用ViewState),那么是的,这是一个问题。尽管如此,它与总体设计更多的是关系,而不是太多的控件。另一方面,如果他们创建了一个通用的用户控件来充当文本框左侧标签的组合(甚至可能是标签+用户可操作控件的每个组合),并且将其散布了在整个应用程序中进行控制,我可以想象您会在页面上看到很多这样的东西,但我看不出为什么这一定会伤害任何东西。