|
3
|
| MindModel · 技术社区 · 17 年前 |
|
|
1
2
首先,你有理由怀疑这个操作需要这么长的时间,xpo在读操作上应该只增加30-70%的开销,在这个很小的数据量上,我们应该说毫秒而不是秒。 在devexpress论坛中有一些通用的性能提示,主要围绕对象缓存、懒惰和深度加载等,但我认为在您的案例中,问题是另外一个问题,不幸的是,很难从您的问题中猜出发生了什么,只是说,它不太可能是xpo的问题,更可能是其他问题。,我倾向于看一下您的会话创建(这也创建了您的对象缓存)和SQL连接代码(IDataStore的东西),如果主机不能被清晰地解决,那么连接通常很慢,如果您不共享/重新使用连接,那么这个问题可能会加剧。 |
|
|
2
1
我不确定你为什么要这样做。如果创建了这样的关联:
然后当您想要填充下拉列表时(如lookupedit控件)
您不必加载a的子项,xpo将根据需要加载它们,并且根本不需要会话管理。 |
|
|
3
0
谢谢你的回答。我创建了一个单独的解决方案,并且能够获得良好的性能,正如您建议的那样。 我的SQL连接正常,可以与应用程序中的其他功能一起使用。 考虑到我正在使用Xaf,并且没有做任何额外的/花哨的事情,我的会话不是由Xaf管理的吗? 我使用的会话是从详细视图中读取的。 |
|
|
4
0
我不确定你的情况,只想和Xaf分享我的一些经验。 第一次单击下拉(查找列表)控件(在详细视图中)时,将有两个查询发送到数据库以填充列表。在我的测试中,有时整个对象都被加载到源集合中,而不仅仅是我们认为的ID和名称属性,这取决于您的对象,您可能希望在列表中使用较轻的属性。您还可以打开列表的服务器模式,然后每次只加载128个对象。 |