ASP.Net过度使用用户控件

Question

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

应用程序的性能非常差（这也是我调查的原因）。每个事件（如单击或下拉选择等）需要约5秒钟才能加载页面（在Visual Studio中为10秒）。该应用程序没有使用Ajax。

跟踪很痛苦，因为aspx页面本身没有代码，因为用户控件处理了所有这些问题，因此跟踪单个页面需要在该页面上的所有用户控件中都放置跟踪语句。

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

编辑： 我不质疑使用用户控件（甚至数量），但只是想知道在页面上拥有如此多的用户控件（每个用户控件都连接数据库，例如）是否会普遍引起性能问题...例如，如果只有一个用户控件回发并做一些操作，那么其他所有用户控件的处理呢？有些是可见的，有些则不可见... David McEwing提到他有40个经过优化的用户控件进行执行等操作，但如果开发人员基于WinForms或“不熟悉asp.net”，那么他们如何确保每个用户控件都被优化了呢...

编辑2：在获取sql语句跟踪后，相同的数据调用每个事件被执行5-6次，因为不同的用户控件需要数据，这些数据没有通用存储，例如，在选项卡中的每个用户控件（上面提到）都进行了相同的调用以从数据库填充对象...我真的不想指责用户控件是问题的根源（我应该删除这个问题吗？）显然问题不在于用户控件，而是在于这种特定情况下对它们的使用...我认为使用过度！

- davidsleeps

---

那时性能并不重要，因为实际上它就像在页面上拥有所有控件一样。真正的问题只是该页面执行了多少工作；这是唯一需要考虑的性能问题，而不是它是否在UserControl中。 - Noon Silk

如果您无法处理用户控件，也许可以将其中一些转换为自定义 Web 控件？不确定预编译是否有帮助，但这只是一个想法。 - johnofcross

Answer 1

单独处理10-20个（甚至更多）用户控件本身并不困难。控件的存在，以及封装思想，绝对不是问题的根源。

当然，没有实际分析应用程序很难精确地得出问题所在，但根据我的经验，更有可能的是每个用户控件内部特定业务逻辑的实现较差。根据您描述的postback需要花费很长时间，每个控件可能会在每次请求时从DAL重新获取其自己的数据。可以通过以下两种方式来缓解这种情况：

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

- Rex M

---

我完全同意你的想法（还有一些想法也是我所持有的）...这加强了我的感觉，即应用程序不是由熟悉asp.net的人开发的，因为Session只用于保存用户ID变量，每个用户控件每次都访问相同的DAL方法。 - davidsleeps

Answer 2

我认为在页面上使用的用户控件数量没有硬性限制。听起来需要进行应用程序级别的跟踪，而不是页面级别的跟踪。可能只有少数几个这些控件会导致问题。或许仅仅一个控件就会引起所有的麻烦。但是，由于无法对“平均”（如果存在这样的概念）用户控件占用资源的水平做出任何假设，因此也无法建议限制。否则，我们将能够提出类成员数量或数据库存储过程数量的类似限制。

现在，如果我们谈论的是每次刷新都会检索自己数据并且每个都带有一堆子控件（无论是否需要）的20个复杂用户控件，那么是有问题的。然而，这更多与整体设计有关，而不是控件过多。另一方面，如果他们创建了一个普通的用户控件，仅作为标签和文本框的组合（甚至是标签+用户可操作控件的每种组合），并将此控件散布在整个应用程序中，我可以想象您会在页面上得到很多这些控件，但我不知道这会对任何事情造成伤害。

- Lloyd McFarlin

Answer 3

我理解你可能不熟悉使用许多用户控件的应用程序？

听起来你可能会得出这个陌生的应用程序方面是导致性能下降的原因的结论。但与其做出假设，不如尝试以下其中一个分析工具来找到答案：

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

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

- John Saunders

---

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

Answer 4

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

我不确定单次使用的UserControl是否有效。它们确实封装和隔离了代码，在繁忙的网页上很好。

您能确定您的UserControls是否被重用，还是其中许多只使用一次？

- DOK

---

封装实际上是用户控件的关键目的，良好封装的一个好处便是重用。 - Rex M

它是混合的。Web应用程序的所有可视元素都存在于用户控件中，因此某些元素出现在所有页面上（例如菜单、标题等，这是有意义的），但其他元素仅出现在与控件相关的单个页面上... - davidsleeps

Answer 5

我同意Saunders的观点，需要进行一些分析以确定某些事情的影响。

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

不过，我认为拥有太多控件可能不是一件好事，就我个人而言。如果没有更多信息，我会暂时说20个控件太多了。

- Noon Silk

---

“20太多了”？你有任何可以引用的来源吗？ - Rex M

我的源代码是我的观点，正如所述。20个自定义用户控件是很多的。这基本上意味着页面正在执行20个操作或显示超过20个数据位，对于单个页面来说这是很多的（根据我的经验）。 - Noon Silk

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

@Silky，这似乎假设每个单独的控件代表了什么范围的工作。我只是担心那些不太懂的初学者会看到“在单个页面上有20个用户控件太多了”，但缺乏足够的上下文，比如“每个UC都做了大量的工作，这对于一个页面来说太多了”。 - Rex M

这并不是一个很大的假设；而且我的帖子有很多背景信息。我认为没有什么可担心的。个人而言，我担心新手来到这里，看到他/她应该为单个页面创建20个用户控件。而用户控件代表的不就是一组工作/项目吗？ - Noon Silk