Xpages 设计元素，托管 bean 限制答案

【问题标题】：Xpages design elements, managed bean limitsXpages 设计元素，托管 bean 限制
【发布时间】：2018-07-10 16:57:48
【问题描述】：

对不起，不是编码问题，不确定我是否应该在这里发布。

我对 Notes nsf 应用程序设计元素中的“大”概念感到困惑，而不是存储的数据或记录的数量。例如，有人说我们不应该有太多的视图，但是“太多”并没有给出任何规模，在它“减速”之前是 10,50,100,500。我意识到它也基于视图设计，但“太多”的一些想法会是有益的。在这种情况下，数据和设计元素在同一个 nsf.xml 中。

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

任何指导将不胜感激。

谢谢

【问题讨论】：

查看次数的问题不在于设计元素的数量，问题在于它们生成的索引。索引更新是昂贵的操作。
感谢 Frantisek，但 30 年过去了，没有关于什么是“大”以及什么是您不了解的指标、文档、示例或经验数据？
您可以拥有数百个视图，但从可维护性的角度来看，是否有更好的方法来处理设计。为什么你需要数百个视图？您可以使用过滤和其他技术来减少对这么多的需求。节省的主要是大小以及开发人员的一些时间和理智。至于设计元素，除了在任何开发环境中的一页上放置大量设计元素之外，我还没有听说过会增加设计时间、出现错误的可能性以及使维护更加困难。
感谢 Eric，我有大约 100 个视图，该应用程序已经发展了很多年，涵盖了业务的许多方面，由于它的结构化方式，可维护性很好。我想我真正的问题是确保将托管 bean、java 类、自定义控件等添加到我的业务逻辑应用程序中没有限制，该应用程序从多个数据库中提取数据到一个大型“wiki”类型的应用程序中。
不，30 年来没有指标。怎么会有？这取决于你的硬件能力——在过去的 30 年里，这方面发生了相当大的变化！它还取决于服务器上的其余负载，这也有很大差异。

标签： xpages lotus-notes lotus-domino

【解决方案1】：

设计元素的数量是有限制的。但除非您将整个 JavaScript 框架导入 NSF，否则您不太可能成功。

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

代码的性能也会产生影响，XPages Toolbox 或代理分析会给出一个想法。 DocumentCollection.count() 很慢，但有时需要。注意收集可能会更快。有各种博客文章涵盖了这一点。

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

但总是在服务器端进行性能增强。 Domino 10 中的 gRPC 将非常高效。因此，请始终尝试使用最新版本并及时了解会议等会议的最新情况，以便您了解 TCO 的改进情况。

如果没有深入了解您的架构和代码，没有人能给您一个明确的答案。

【讨论】：

简而言之，实际上并不是元素的数量更多的是其中包含的内容或它们的设计方式。我总是更新到最新版本，但希望我从未见过 FP10，但那是另一回事了。非常感谢您一如既往地提供信息。