Службы WCF RIA в SL List.count () получают общее количество элементов, несмотря на EntityQuery, составленный на стороне клиента - PullRequest
0 голосов
/ 18 апреля 2011

У меня есть приложение SL4, которое использует службы WCF RIA и LINQ2SQL.

Я создаю EntityQuery на стороне клиента и хочу получить количество элементов в списке на стороне сервера, но список.count () не учитывает установленный объект EntityQuery.Показывает общее количество элементов, но отправляет правильное количество элементов клиенту.

Метод DomainService:

public IQueryable<Invoice> GetMyInvoices(string userID, int numberInCache)
    {
        IQueryable<Invoice> myList = this.DataContext.Invoices.Where(s => s.userID == userID);

        if (numberInCache > 0)
        {
            if (myList.Count() == numberInCache)
            {
                return null;
            }
        }
        return myList;
    }

На стороне клиента:

EntityQuery<Invoice> query = myDataContext.GetMyInvoicesQuery(userID, numberInCache).Where(i => i.deliveryDate.month == 4);

        LoadOperation<Invoice> lo = tetelSearchContext.Load(query,
            (result) =>
            {
                if (!result.HasError)
                {
                    foundTetels = result.Entities;
                }
                else
                {
                    MessageBox.Show(result.Error.Message);
                    result.MarkErrorAsHandled();
                }
            }
        , null);

На стороне клиента я получаю правильный счетчик списка, но на стороне сервера он не учитывает фильтр deliveryDate.month.

Что я сделал не так?

Заранее спасибо

Габор


Спасибо за разъяснения.

В моей ситуации приложение должно предвидеть, когда запрашиваемые объекты являются подмножеством набора сущностей на стороне клиента.

Я подумал, самый простой способ решить, сравнить число объектов после фильтрацииEntitySet на клиенте и применение того же фильтра на сервере.

Приложение должно загружать записи с сервера, только когда количество различий.

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

Например: запросите счета за первый квартал, затем запросите счета в январе.

Поскольку у меня много условий, неясно, содержит ли клиент все записи на клиенте, илине.(Если мы запросим все счета в январе, после получения оплаченных счетов в первом квартале, клиентский набор сущностей будет содержать только все записи, если все счета будут оплачены в январе.)

Поэтому я подумал, что это более эффективносначала получить количество объектов на сервере, а затем при необходимости загрузить EntitySet.

У кого-нибудь есть лучшее решение?

Заранее спасибо,

Gabor.

1 Ответ

0 голосов
/ 18 апреля 2011

Хорошо, сначала позвольте мне рассказать вам, как работают службы RIA.

  1. RIA-клиент составляет запрос
  2. RIA-клиент отправляет некоторый сложный XML на сервер
  3. RIA-сервис(На стороне сервера) сначала вызывает GetMyInvoices
  4. Обратите внимание, что запрос вашего клиента еще не применен
  5. Служба RIA затем принимает возвращаемое значение вашего запроса, возвращенного методом GetMyInvoices
  6. RIAСлужбы теперь применяют XML, отправленный клиентом
  7. Службы RIA возвращают результат клиенту

Итак, теперь посмотрим на ваш шаг 3, в ваших GetMyInvoices вы применяете небольшой запрос к своему контексту,независимо от того, что клиент отправил вам.Фильтр составленных запросов вашего клиента применяется на последнем шаге.

Вместо этого вы должны вызывать два запроса один за другим на стороне клиента: 1. Сначала получить счетчик результатов 2. Если он не совпадает, то выберите вашrecords

Однако, из любопытства, почему вы вообще хотите что-нибудь увидеть на стороне сервера?Позвольте серверу отправлять вам результаты запроса даты напрямую, поскольку вы можете реализовать разбиение на страницы и т. Д., Вы не добьетесь высокой производительности, разбив такой запрос и управляя запросом на стороне клиента и на стороне сервера.

...