Xpages设计元素、托管bean限制

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

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

是否有关于元素数量的建议，如XPages、自定义控件、托管bean、Java类等。哪些元素被认为是多余的？在本例中，我将数据和逻辑放在单独的NSF中

任何指导都将不胜感激

---

谢谢

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

如前所述，视图性能取决于许多因素。500个设计得体的视图就可以了。50个表现不佳的视图可能是不好的。列上的大量索引会影响需要创建和管理的索引数量。在视图选择公式或列公式中使用

@今天

或

@现在

将是一个大问题。拥有大量很少更改的文档、每30秒更新一次的文档数量较少、大量用户定期更新—这些都会影响性能

代码中的性能也会影响性能，XPages工具箱或代理评测将提供一个思路

DocumentCollection.count（）

速度较慢，但有时需要。记事本收集可能更快。有各种各样的博客文章介绍了这一点

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

但在服务器端总是有性能增强。Domino10中的gRPC将非常出色。因此，请始终尝试使用最新版本，并与会议等会议保持同步，以便了解TCO的改进情况

---

归根结底，如果不深入了解您的体系结构和代码，没有人能够给您一个明确的答案。

视图计数的问题不在于设计元素的数量，而在于它们生成的索引。索引更新是一项昂贵的操作。感谢Frantisek，但是30年来，没有任何度量、文档、示例或经验数据来说明什么是“大的”，什么是你所不知道的？你可以有上百个视图，但从可维护性的角度来看，有没有更好的方法来处理设计。为什么您需要数百个视图？您可以使用过滤和其他技术来减少对如此多数据的需求。节省的主要是规模、开发人员的时间和理智。至于设计元素，除了在任何开发环境中在一个页面上放置大量设计元素会增加设计时间、出现错误的可能性并使维护变得更加困难之外，我还没有听说过任何其他设计元素。谢谢Eric，我有大约100个视图，该应用程序经过多年的发展，涵盖了业务的许多方面，因为它的结构和可维护性很好。我想我真正的问题是确保在我的业务逻辑应用程序中添加托管bean、java类、自定义控件等没有限制。我的业务逻辑应用程序正在将数据从多个数据库拉到一个大型“wiki”类型的应用程序中。不，30年来没有任何指标。怎么会有呢？这取决于你的硬件能力——在过去的30年里，这方面已经发生了相当大的变化！它还取决于服务器上的其他负载，这些负载也有很大的不同。简而言之，这实际上不是元素的数量，而是元素中包含的内容或它们的设计方式。我总是更新到最新的版本，希望我从未见过FP10，但这是另一个故事。非常感谢您一如既往的回复。