跨多个数据库的Xpages

我们将从

XPages

开始，我有以下问题：

我们有一个由几个Notes数据库组成的系统。现在，我们都想添加一个XPage，以便可以在浏览器和客户端中编辑它。 现在更好的是： 带有

XPages

的数据库以及从其他数据库获取的编程和数据。 所有数据库都获得

XPages

，并通过导航单独寻址

---

对我来说，什么对性能更好

最佳实践是在单个NSF中存储每个“应用程序”的所有XPage设计元素。这可以是与某些数据相同的容器，也可以是完全独立的NSF。但您绝对应该避免将XPage元素存储在单独的nsf中，因为数据恰好存储在多个nsf中

相反，在XPage应用程序中，即使数据存储在同一NSF中，也应始终从理论上将其与用户界面分开。这一理念使得为应用程序设计现代、直观的用户界面变得更加容易，而不会因为后端数据的结构而限制这些设计决策

每个NSF的ACL仍然受到尊重，因此，如果您对每个数据库施加了不同的访问级别，则用户仍然只能基于包含每个记录的NSF的ACL访问他们有权访问的内容，而不管包含XPage设计元素的NSF的ACL如何

一个相当具体的性能考虑是，和会话作用域对于包含用户当前正在访问的XPage元素的NSF是唯一的。因此，例如，如果您的应用程序由6个数据库组成，并且您在这些数据库中拆分了XPage设计元素，那么您将无法在所有应用程序中缓存配置设置或其他计算代价高昂的查询。相反，如果所有XPage设计元素都在一个NSF中，则只有一个应用范围。因此，用户界面的每个部分都可以访问界面的任何其他部分已经缓存的信息——不仅跨越应用程序中的不同页面，还跨越用户：如果为一个用户检索的数据应该是返回给所有用户的相同数据，则为一个用户缓存该数据将为所有用户缓存该数据

类似地，由于用户在其访问的每个NSF中具有不同的会话范围，因此当用户导航到不同的NSF时，应用程序所有区域中适用的任何用户首选项（或行为）都将被忘记

将不同的XPage元素存储在不同的NSF中，仅仅因为数据所在的位置就消除了这些以及其他性能和接口优化的机会。对于这种类型的开发新手来说，分离设计可能会更简单，但最终最终用户体验肯定会受到影响，他们可能会有意识地意识到这一点。但通常情况下，他们会感到困惑和沮丧，无法准确地找出原因

---

简而言之，以下是确定每个XPage应该位于何处的最佳方法：如果从一个XPage导航到另一个XPage的最终用户假设他们仍然在同一个应用程序中，那么无论每个XPage访问的数据位于何处，这两个XPage都应该位于同一个NSF中。

谢谢您的回答。这也是我喜欢的方式。