Xpages设计元素，托管bean限制

Question

抱歉，没有编码问题，不确定我是否应该在此处发布。

我很难理解Notes nsf应用程序设计元素中“大”的概念，而不是存储的数据或记录的数量。例如，有人说我们不应该有太多的观点，但是“太多”并不能给出任何比例，在它“变慢”之前是10,50,100,500。我也基于视图设计来意识到这一点，但是一些“太多”的想法将是有益的。在这种情况下，数据和设计元素位于同一nsf中。

是否有关于XPages，自定义控件，托管Bean，Java类等元素数量的建议。什么被认为过多？在这种情况下，我在单独的nsf中具有数据和逻辑。

任何指导将不胜感激。

谢谢

Answer 1

设计元素的数量受到限制。但是除非您将整个JavaScript框架导入NSF，否则您不太可能会遇到它。

如上所述，视图性能取决于许多因素。 500个设计得体的视图很好。 50个效果不佳的视图可能很糟糕。列上的许多手段都会影响需要创建和管理的索引的数量。在视图选择公式或列公式中使用@Today或@Now将是一个大问题。有很多很少更改的文档，每30秒更新的文档数量较少，很多用户定期更新-所有这些都会影响性能。

代码的性能也将受到影响，XPages Toolbox或代理配置文件将提供一个思路。 DocumentCollection.count()很慢，但有时是必需的。注意收集可能会更快。有很多关于此的博客文章。

具有不断增长的Map的托管bean将影响Java内存。

但是总是在服务器端进行性能增强。 Domino 10中的gRPC将表现出色。因此，请始终尝试使用最新版本，并及时了解会议上的会议情况，以便您了解正在改善的总体拥有成本。

底线是您对您的体系结构和代码没有深入的了解，没有人能够给您确定的答案。