ASP.Net 过度使用用户控件

Posted 2023-03-08

【中文标题】ASP.Net 过度使用用户控件

【英文标题】：ASP.Net excessive use of User Controls

【发布时间】：2010-11-20 02:51:23

【问题描述】：

我正在研究一个在每个页面上广泛使用用户控件的 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 次，因为不同的用户控件需要通常不存储的数据，例如选项卡中的每个用户控件（如上所述）都进行相同的调用以从数据库中填充对象...我真的不是在这里指责用户控件是问题（我应该删除问题吗？）显然是问题不是用户控件，而是在这种特殊情况下使用它们......我认为这太过分了！

【问题讨论】：

当时与性能无关，因为实际上它就像将控件全部放在页面上一样。真正的问题是该页面做了多少工作。这是唯一的性能考虑。如果它恰好在 UserControl 中，则不会。

如果您对用户控件无能为力，也许您可​​以将其中一些转换为自定义 Web 控件？不确定预编译是否会有所帮助，但只是一个想法。

【参考方案1】：

我将坚定地站在那些认为应该在页面上使用的用户控件的数量没有硬性限制的人的阵营中。听起来应用程序范围的跟踪在这里是有序的，而不是页面级的跟踪。很可能是这些控件中的一小部分导致了问题。哎呀，它可能是一个引起所有大惊小怪的单一控制。但是，由于不可能对“平均”（如果有的话）用户控制占用的资源使用水平做出任何假设，因此同样不可能提出限制。否则，我们将能够对类的成员数量或数据库的存储过程数量提出类似的限制。

现在，如果我们谈论的是 20 个复杂的用户控件，每个控件在每次刷新时都检索自己的数据，并且每个控件都有一堆使用 ViewState 的子控件（无论是否需要），那么是的，这是个问题。尽管如此，它更多地与整体设计有关，而不是控制太多。另一方面，如果他们创建了一个通用的用户控件来充当文本框左侧标签的组合（或者甚至可能是标签 + 用户可操作控件的每个组合）并且已经洒了这个控制整个应用程序，我可以想象你会在一个页面上得到一堆这些，我不明白为什么这必然会伤害任何东西。

【参考方案2】：

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

如果不实际分析应用程序当然不可能准确地说出问题所在，但根据我的经验，我可以这样说：

更有可能是每个用户控件内部的业务逻辑的具体实现很差。回发所花费的时间与您描述的一样长，每个控件可能会在每个请求中回溯到您的 DAL 以获取其自己的数据。这可以通过两件事来缓解：

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

【讨论】：

我完全同意你的想法（我也有想法）......这再次强化了我的感觉，即该应用程序不是由熟悉 asp.net 的人开发的会话除了保存用户 id 变量之外不使用，并且每个用户控件每次都访问相同的 DAL 方法

【参考方案3】：

我同意 Saunders 关于做一些分析以确定某些事情的影响。

请注意，您可以在这里获得一些免费的 IIS 压力测试工具：http://support.microsoft.com/kb/840671

不过，我要说的是，拥有太多控件可能不是一件好事，恕我直言。不知道更多，我姑且说 20 太多了。

【讨论】：

“20 太多了”？你有什么可以引用的资料吗？

我的来源是我的意见，如上所述。 20 个自定义用户控件很多。它基本上意味着页面正在做 20 件事或显示超过 20 位数据，这对于单个页面来说很多（根据我的经验）。

我同意。特别是如果一个选项卡控件没有显示，但它仍在创建它的用户控件，那么这将导致一些不必要的开销，但在不知道更多的情况下，我已经成功地在页面上使用了 40 多个优化的用户控件，用于非常特定的目的和业务规则封装.

@Silky 似乎对每个单独控件所代表的工作范围做出了很大的假设。我只是担心那些偶然发现这一点并在没有足够上下文的情况下看到“单个页面上的 20 个用户控件太多”的可怜的初学者，比如可能“20 个 UC，每个都做大量的工作对于单个页面来说太多了"。

这根本不是什么大假设；我的帖子有很多背景。我不认为有什么可担心的。就我个人而言，我担心新手出现并看到他/她应该为单个页面创建 20 个用户控件。除了一组要完成的工作/项目之外，用户控件还代表什么？

【参考方案4】：

我相信 UserControls 的主要目的之一是代码重用。也就是说，如果相同的功能出现在多个网页上，那么最好为其创建一个 UserControl。这不仅使开发人员不必将相同的代码编写（或复制和粘贴）到多个网页，而且还使维护变得更加容易。对 UserControl 所做的任何更改都会在使用 UserControl 的任何地方自动实现。维护开发人员不必担心找到代码需要更改的所有不同位置。

我不确定一次性用户控件是否同样有效。它们确实封装和分离代码，这在繁忙的网页上非常有用。

您能否确定您的 UserControl 是否被重复使用，或者它们中的许多是否只使用过一次。

【讨论】：

封装实际上是用户控件的关键目的，复用是良好封装的好处之一。

它是混合的。 Web 应用程序的所有视觉元素都存在于用户控件中，因此有些元素出现在所有页面上（例如菜单、标题等，这是有意义的），而另一些则只出现在与控件相关的单个页面上......

【参考方案5】：

我认为您不熟悉使用这么多用户控件的应用程序？

听起来您可能会得出这样的结论：应用程序的这个不熟悉的方面是不熟悉的糟糕性能的原因。与其做出假设，不如尝试以下分析工具之一，并找出答案：

JetBrains' dotTrace Red-Gate ANTS Automated QA's AQTime

这些都可以对 ASP.NET 应用程序进行内存和 CPU 分析。

【讨论】：

我对这么多用户控件不太熟悉...我当然在我从事的所有 asp.net 项目中都使用过它们，但我倾向于将每个页面都视为已映射更接近业务对象，然后在这些页面上使用用户控件，而不是由用户控件组成的页面的所有部分......