我正在调查一个在每个页面上广泛使用用户控件的asp.net Web应用程序。大多数页面包含大约10-20个用户控件。用户控件似乎是业务对象的可视化表示（如果这是有意义的），尽管具有更精细的粒度，例如选项卡控件的每个选项卡，其内容在用户控件中。该项目本身有200多个用户控件（ascx文件）。
应用程序的性能非常差（我正在研究的原因）。每个事件（例如点击或下拉选择等）都需要大约5秒的时间来加载页面（在visual studio中为10秒）。该应用程序没有使用Ajax。
跟踪很痛苦，因为aspx页面本身在代码隐藏中没有代码，因为用户控件会查看所有这些代码，因此跟踪单个页面需要该页面上所有用户控件中的跟踪语句。
我实际上认为让每个用户控件查看其业务代码并可重复使用是一个明智的想法，但过度使用用户控件会导致性能下降？这看起来像是由具有强大WinForms背景的人编写的asp.net应用程序的结构吗？
修改
我想我应该补充一点，我不是在质疑用户控件的使用（甚至数量），而只是在页面上有这么多东西（例如每个用户控件连接到数据库）都会导致性能问题...例如，如果只有一个用户控制回发来做某事，那么所有其他的处理，有些是可见的，有些则不是...... @ David McEwing提到他有40个优化的用户控件执行等，但如果开发人员是基于WinForms或“不熟悉asp.net”，那么他们将如何确保每个人都进行优化...
EDIT2
在获得sql语句跟踪之后，对于每个事件，每次页面调用正在执行相同的数据调用5-6次，因为不同的用户控件需要通常不存储的数据，例如，选项卡中的每个用户控件（如上所述）进行相同的调用以从数据库填充对象...我真的不是在这里指责用户控件是问题（我应该删除问题吗？）显然问题不是用户控件，但在这种特殊情况下使用它们......我认为这是过度的！
答案 0 :(得分：10)
10-20（甚至数百）用户控制本身就是微不足道的。控件本身的存在以及封装的想法绝对不是您问题的根源。
如果没有实际分析应用程序当然不能说正好问题是什么，但根据我的经验，我可以这样说：
更有可能的是，每个用户控件中的业务逻辑的特定实现很差。由于回发只需要您描述，每个控件可能会回顾您的DAL，以获取每个请求的数据。这可以通过两件事来缓解：
答案 1 :(得分：5)
我会坚定地站在人们的阵营中，这表明对页面上应该使用的一些用户控件没有硬性限制。这听起来像是应用程序范围的跟踪，而不是页面级跟踪。很可能是少数这些控件导致了问题。哎呀，它可能是一个单一的控制引起所有的大惊小怪。但是，由于不可能对资源使用水平做出任何假设，即“平均”（如果有这样的事情）用户控制占用，同样不可能建议限制。否则，我们将能够对类的成员数量或数据库的存储过程数量提出类似的限制。
现在，如果我们谈论的是20个复杂的用户控件，每个用户控件都会在每次刷新时检索自己的数据，并且每个用户都使用ViewState进行一系列子控件，无论是否需要，那么是的，这是一个问题。尽管如此，它还是与整体设计有关，而不是控制太多。另一方面，如果他们创建了一个通用的用户控件，只能作为文本框左侧标签的复合（或者甚至是标签+用户可操作控件的每个组合），并且已经将在整个应用程序中控制，我可以想象你会在页面上得到一堆这些，我不明白为什么这会伤害任何东西。
答案 2 :(得分：2)
我认为您不熟悉使用这么多用户控件的应用程序？
听起来你可能会得出结论，这个应用程序的这个不熟悉的方面是导致不熟悉的不良表现的原因。为什么不尝试使用以下分析工具之一，而不是做出假设，并找出：
这些都可以对ASP.NET应用程序进行内存和CPU分析。
答案 3 :(得分：1)
我认为UserControls的一个关键目的是代码重用。也就是说，如果在多个网页上发生相同的功能，那么最好为它创建一个UserControl。这不仅可以避免开发人员将相同的代码写入（或复制和粘贴）到多个网页，而且还可以使维护变得更加容易。对UserControl所做的任何更改都会在使用UserControl的任何位置自动实现。维护开发人员不必担心找到代码需要更改的所有不同位置。
我不确定一次性使用UserControl是否同样有效。它们封装和隔离代码，这在繁忙的网页上很不错。
您能否确定您的UserControls是否被重复使用，或者其中许多只使用过一次。
答案 4 :(得分：1)
我同意Saunders关于做一些分析以确定某些事情的影响。
请注意，您可以在此处获取一些免费的IIS压力测试工具：http://support.microsoft.com/kb/840671
但是，我会说，控制太多可能不是一件好事，恕我直言。在不知情的情况下，我暂时说20太多了。