ASP.NET过度使用用户控件

仅10-20(甚至数百)个用户控件就非常简单。控件本身的存在以及封装的想法绝对不是问题的根源。

不可能说 精确地 当然,在没有实际分析应用程序的情况下,问题是什么,但根据我的经验,我可以这样说:

更可能的是 具体实施 每个用户控件内部的业务逻辑都很差。当回发需要尽可能长的时间来描述时,每个控件可能会回过头来查看DAL中每个请求的数据。这可以通过以下两件事来缓解:

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

我将把自己牢牢地放在人们的阵营中,他们认为应该在一个页面上使用的一些用户控件没有严格的限制。这听起来像是应用程序范围的跟踪,而不是页面级别的跟踪。很可能是这些控制措施中的一小部分导致了这个问题。见鬼,这可能是一个单一的控制导致所有的麻烦。然而,由于不可能对“平均”(如果有这样的事情)用户控制所占的资源使用水平做出任何假设,因此也不可能提出限制。否则,我们就可以对类的成员数或数据库的存储过程数提出类似的限制。

现在,如果我们谈论的是20个复杂的用户控件,每个控件都在每次刷新时检索自己的数据,每个控件都有一组子控件,不管是否需要,都使用viewstate,那么是的,这是一个问题。不过,它与总体设计的关系比控制太多的关系更大。另一方面,如果他们创建了一个普通的用户控件来充当文本框左侧标签的组合(或者甚至是标签+用户可操作控件的每个组合),并且在整个应用程序中散布了这个控件,我可以想象你会在一个页面上得到一堆这样的控件,我不明白为什么会出现这种情况。不必要地伤害任何东西。

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

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

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

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

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

我不确定一次性用户控件是否有效。他们确实封装并创建了代码,这在繁忙的网页上很好。

您能否确定您的用户控件是否被重用,或者其中许多控件只使用一次。

我同意桑德斯做一些分析来确定某些事情的影响。

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

不过,我要说的是,控制太多可能不是件好事,imho。不知道更多,我会暂时说20太多了。