我的成员将能够使用 X 数量的小部件自定义他们的个人资料页面，每个小部件显示不同的数据，例如音乐列表、他们关注的人员列表等。
几个小部件包括： - 他们上传的媒体列表 - 他们关注的人员列表 - 关注他们的人员列表 - Html/文本小部件 - 媒体统计（下载数量等） - 其他成员留下评论的评论小部件
一些小部件必须对返回的数据进行分页，因为可能有数百个结果。
我目前还没有进行任何优化，因此它正在做大量的数据库工作来返回所有数据......检索数据的最有效方法是什么......每个小部件 1 个数据库调用是否可以接受？每页可能有大约 5-20 个小部件。
如果您需要有关我的情况的更多信息，请随时询问。
保罗
简短的回答：这取决于。
从未优化状态开始，然后使用 SQL 分析器或 dotTrace 之类的 C# 分析器找出进行改进的最佳位置。设定一个切实可行的目标（例如，“加载页面的时间少于 800 毫秒”）。
一般来说，我发现在请求中调用大约 20-30 次数据库后性能开始下降，但这取决于您的服务器、数据库的位置等。
您可以尝试很多事情：预缓存、使用连接而不是选择等的急切获取等。除非智能应用，否则没有什么能保证更好的性能。
对于包含大量小部件的页面，一种常见的设计模式是使用 AJAX 异步加载每个小部件，而不是一次性加载整个页面。
由于您已将工作缩减到小部件，因此正确的做法是让每个小部件对其所有必需的功能进行一次查询。即使您通过 AJAX 检索小部件也是如此（正如 cbp 指出的那样，这不是一个坏主意）。
其次，我会为每个小部件设置某种机制来注册它的存在，然后在所有小部件都注册之后，我将触发一个包含所有小部件查询的单个查询。（从技术上讲，它又是多个查询，但在一次往返中，请参阅 NH 参考中的 MulriCriteria 和 MultiQueries）。
也不要忘记延迟加载是隐藏的数据库检索，并且在急切加载适当的情况下使用延迟加载可能会对性能产生巨大影响（例如 Foo.Bar.Name ，您总是显示 Bar.Name 值时你呈现 Foo 实体）
即使每个请求少于 20-30 次数据库调用，性能也会下降，但这取决于您的实体、查询、过滤器的大小和复杂性以及检索到的数据集的大小。