DevExpress eXpressApp Framework (XAF) и eXpress Persistent Objects (XPO): как ускорить время загрузки ассоциаций?

Question

У меня проблема со скоростью доступа к свойству ассоциации с большим количеством записей.

У меня есть приложение XAF с родительским классом с именем MyParent.

В MyParent.

230 записей.

MyParent имеет дочерний класс с именем MyChild.

Есть 49 000 записей в MyChild.

У меня есть связь, определенная между MyParent и MyChild стандартным способом:

В MyChild:

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

А в MyParent:

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

Существует специальная запись MyParent, которая называется MyParent1.

Для MyParent1 существует 630 MyChild записей.

У меня есть DetailView для класса с именем MyUI.

Пользователь выбирает элемент в одном раскрывающемся списке в MyUI DetailView, и мой код должен заполнить другой раскрывающийся список MyChild объектами.

Пользователь выбирает MyParent1 в первом раскрывающемся списке.

Я создал свойство в MyUI для возврата коллекции MyChild объектов для выбранного значения в первом раскрывающемся списке.

Вот код для собственности:

[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, поскольку оно требуется только для пользовательского интерфейса DetailVIew. Я не думаю, что сохранение его ускорит создание коллекции в первый раз, и после того, как она используется для заполнения раскрывающегося списка, она мне не нужна, поэтому я не хочу тратить время на ее хранение.

Проблема в том, что для вызова theParentValue = this.DropDownOne.

требуется 45 секунд.

Технические характеристики:

• Vista Business
• 8 ГБ ОЗУ
• 2,33 ГГц E6550
• SQL Server Express 2005

Это слишком долго для пользователей, чтобы ждать одного из множества раскрывающихся списков в DetailView.

Я нашел время, чтобы набросать экономическое обоснование, потому что у меня есть два вопроса:

1. Как я могу ускорить загрузку связанных значений?

2. Есть ли другой (простой) способ программирования раскрывающихся списков и DetailView, который работает намного быстрее?

Да, вы можете сказать, что 630 - это слишком много элементов для отображения в раскрывающемся списке, но этот код занимает так много времени, я подозреваю, что скорость пропорциональна 49 000, а не 630. 100 элементов в выпадении Даундаун не будет слишком большим для моего приложения.

Мне нужно довольно много таких выпадающих списков в моем приложении, поэтому нецелесообразно заставлять пользователя вводить более сложные критерии фильтрации для каждого из них. Пользователь должен выбрать одно значение и увидеть соответствующие значения.

Я бы понял, если бы поиск большого количества записей был медленным, но поиск нескольких сотен не должен занимать так много времени.

Answer 1

Во-первых, вы правы, что скептически относитесь к тому, что эта операция займет так много времени, XPO при операциях чтения должна добавить только 30–70% накладных расходов, и при этом крошечном объеме данных мы должны говорить миллисекунды, а не секунды.

Некоторые общие советы по улучшению доступны на форумах DevExpress и касаются кеширования объектов, ленивых и глубоких загрузок и т. Д., Но я думаю, что в вашем случае проблема заключается в другом, к сожалению, очень трудно угадать, что происходит с вашим Вопрос только для того, чтобы сказать, что вряд ли это будет проблемой с XPO, скорее всего это будет что-то еще, я был бы склонен взглянуть на создание вашего сеанса (это также создает кэш вашего объекта) и код соединения SQL (материал IDataStore) , Соединения часто бывают медленными, если узлы не могут быть разрешены без ошибок, и если вы не используете или повторно используете соединения, эта проблема может усугубиться.

Answer 2

Я не уверен, почему вы будете делать это так, как вы. Если вы создали ассоциацию, подобную этой:

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 будет загружать их по мере необходимости, и для этого совсем не нужно управление сеансами.

Answer 3

Я не уверен в вашем случае, просто хочу поделиться своим опытом с XAF.

При первом щелчке элемента управления раскрывающегося списка (в подробном представлении) в базу данных будут отправлены два запроса для заполнения списка. В моих тестах иногда весь объект загружался в исходную коллекцию, а не только свойства ID и Name, как мы думали, так как это зависит от ваших объектов, которые вы можете использовать для списков более легких. Вы также можете включить режим сервера в списке, тогда каждый раз загружается только 128 объектов.

Answer 4

Спасибо за ответ. Я создал отдельное решение и смог добиться хорошей производительности, как вы предлагаете.

Мое соединение SQL в порядке и работает с другими функциями приложения.

Учитывая, что я использую XAF и ничего особенного не делаю, разве мои сеансы не управляются XAF?

Сеанс, который я использую, читается из DetailView.