代码之家  ›  专栏  ›  技术社区  ›  MindModel

devexpress expressapp框架(xaf)和express persistent objects(xpo):如何加快关联的加载时间?

  •  3
  • MindModel  · 技术社区  · 17 年前

    访问具有大量记录的关联属性的速度有问题。

    我有一个名为xaf的父类应用程序 MyParent .

    有230条记录 我的父母 .

    我的父母 有一个名为 MyChild .

    有49000条记录 我的孩子 .

    我定义了 我的父母 我的孩子 以标准方式:

    我的孩子 :

    // MyChild (many) and MyParent (one)
    [Association("MyChild-MyParent")]
    public MyParent MyParent;
    

    而在 我的父母 :

    [Association("MyChild-MyParent", typeof(MyChild))]
    public XPCollection<MyCHild> MyCHildren
    {
         get { return GetCollection<MyCHild>("MyCHildren"); }
    }
    

    有一个特定的 我的父母 记录称为 MyParent1 .

    为了 霉素1 有630个 我的孩子 记录。

    我对一个叫做 MyUI .

    用户在 姆尤伊 详细视图,我的代码必须用 我的孩子 物体。

    用户选择 霉素1 在第一个下拉列表中。

    我在 姆尤伊 返回的集合 我的孩子 第一个下拉列表中选定值的对象。

    这是酒店的代码:

    [NonPersistent]
    public XPCollection<MyChild> DisplayedValues
    {
        get
        {
            Session theSession;
            MyParent theParentValue;
            XPCollection<MyCHild> theChildren;
    
            theParentValue = this.DropDownOne;
            // get the parent value
    
            if theValue == null)
            {
                // if none
    
                return null;
                // return null
            }
    
            theChildren = theParentValue.MyChildren;
            // get the child values for the parent
    
            return theChildren;
            // return it
        }
    

    我标记了 DisplayedValues 属性为 NonPersistent 因为它只需要用于详细视图的UI。我不认为坚持它会在第一次加速收集的创建,在它被用来填充下拉列表之后,我不需要它,所以我不想花时间存储它。

    问题是打电话要45秒 theParentValue = this.DropDownOne .

    规格:

    • 商业版
    • 8 GB RAM
    • 2.33 GHz E6550处理器
    • SQL Server Express 2005

    这对于用户来说太长了,无法等待detailview中的许多下拉列表之一。

    我花时间草拟了商业案例,因为我有两个问题:

    1. 如何使关联值加载更快?

    2. 是否有其他(简单)方法来编程下拉列表和详细视图,使其运行得更快?

    是的,您可以说630是太多的项目,无法在下拉列表中显示,但此代码花费了太长时间,我怀疑速度与49000成比例,而不是630。下拉列表中的100个项目对我的应用程序来说不会太多。

    我的应用程序中需要很多这样的下拉列表,所以强制用户为每个下拉列表输入更复杂的筛选条件是不合适的。用户需要选择一个值并查看相关值。

    如果发现大量的记录很慢,我会理解的,但是找到几百条不需要那么长时间。

    4 回复  |  直到 14 年前
        1
  •  2
  •   Tim Jarvis    17 年前

    首先,你有理由怀疑这个操作需要这么长的时间,xpo在读操作上应该只增加30-70%的开销,在这个很小的数据量上,我们应该说毫秒而不是秒。

    在devexpress论坛中有一些通用的性能提示,主要围绕对象缓存、懒惰和深度加载等,但我认为在您的案例中,问题是另外一个问题,不幸的是,很难从您的问题中猜出发生了什么,只是说,它不太可能是xpo的问题,更可能是其他问题。,我倾向于看一下您的会话创建(这也创建了您的对象缓存)和SQL连接代码(IDataStore的东西),如果主机不能被清晰地解决,那么连接通常很慢,如果您不共享/重新使用连接,那么这个问题可能会加剧。

        2
  •  1
  •   Steven Evers    17 年前

    我不确定你为什么要这样做。如果创建了这样的关联:

    public class A : XPObject
    {
        [Association("a<b", typeof(b))]
        public XPCollection<b> bs { get { GetCollection("bs"); } }
    }
    
    public class B : XPObject
    {
        [Association("a<b") Persistent("Aid")]
        public A a { get; set; }
    }
    

    然后当您想要填充下拉列表时(如lookupedit控件)

    A myA = GetSomeParticularA();
    lupAsBs.Properties.DataSource = myA.Bs;
    lupAsBs.Properties.DisplayMember = "WhateverPropertyName";
    

    您不必加载a的子项,xpo将根据需要加载它们,并且根本不需要会话管理。

        3
  •  0
  •   MindModel    17 年前

    谢谢你的回答。我创建了一个单独的解决方案,并且能够获得良好的性能,正如您建议的那样。

    我的SQL连接正常,可以与应用程序中的其他功能一起使用。

    考虑到我正在使用Xaf,并且没有做任何额外的/花哨的事情,我的会话不是由Xaf管理的吗?

    我使用的会话是从详细视图中读取的。

        4
  •  0
  •   Tien Do    16 年前

    我不确定你的情况,只想和Xaf分享我的一些经验。

    第一次单击下拉(查找列表)控件(在详细视图中)时,将有两个查询发送到数据库以填充列表。在我的测试中,有时整个对象都被加载到源集合中,而不仅仅是我们认为的ID和名称属性,这取决于您的对象,您可能希望在列表中使用较轻的属性。您还可以打开列表的服务器模式,然后每次只加载128个对象。

    推荐文章