Услуги .Net WCF RIA: на страницу или на страницу?и сколько данных отправить по трубе

Question

Итак, у меня была дискуссия с моим коллегой о Службах RIA WCF и о том, сколько именно данных мы отправляем клиенту в данном запросе.Вот настройка:

Мы создаем приложение для создания отчетов в Silverlight и извлекаем данные из службы RIA WCF для заполнения различных таблиц и диаграмм.У нас есть две разные идеи относительно того, как реализовать сервис.Есть несколько предостережений, которые важны для принятия этого решения.

Предупреждение 1:"Отчет" может быть любым количеством таблиц / диаграмм, но, скорее всего, он будет состоять только из несколькихкаждый.

Предупреждение 2: Полный размер таблицы данных может составлять тысячи строк.

Предупреждение 3: Некоторые таблицы будут содержать 50+ колонки (не наша идея ...).Пользователям потребуется возможность показывать скрытые столбцы, потому что, если честно, кто мог бы ассимилировать столько данных одновременно?

У нас есть две разные идеи:

1. СоздатьData Contract для каждой таблицы / диаграммы и отдельный GetTableX()/GetChartX() метод обслуживания для каждой.Мы будем использовать доменную службу для этого, чтобы фильтрация / сортировка / разбиение по страницам могли обрабатываться на сервере, и возвращалось только определенное количество объектов.

   Поскольку «Отчет» может содержать n таблиц / диаграмм, это будет означать отправку n запросов при каждой загрузке Report и дополнительный запрос для каждой страницы таблицы.

   Служба также будет несколько многословной, 15 отчетов (что неизбежно будет расти), возможно, с 3-5 методами на отчет может означать от 45 до 75 методов.

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

2. Создать объект Report для каждого отчета с набором сеток / диаграмм,вместе с данными для каждой диаграммы / таблицы, отфильтрованные по критериям, универсальным для каждого отчета.Сериализуйте и передайте объект отчета обратно клиенту, позволяя Silverlight обрабатывать разбиение на страницы / сортировку / фильтрацию.

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

   Я не уверен, так как я недостаточно исследовал, но нам, вероятно, пришлось бы углубиться в WCF RIA Services, чтобы заставить это работать, или нам, возможно, лучше отсканировать RIA и сделатьнаша собственная вещь на вершине WCF.Однако это даст нам гибкость в выборе столбцов, которые нужно отправлять в браузер в сценарии скрытия / отображения столбцов, что приведет к снижению общей полезной нагрузки, проходящей через строку.

tl; dr = Лучше ли посылать все данные по сети один раз или пейджировать?

1. Кажется, ответ сильно зависит от того, сколько данных, но как вы, ребята, принимаете это решение?

2. Сколько данных нужно отправить в запросе?Когда пейджинг становится более эффективным?или, по крайней мере, внешне более эффективно для пользователя? **

3. С точки зрения бизнеса, когда лучше просто использовать встроенные инструменты, а не использовать свои собственные.Предположим, что ваш собственный будет более эффективным, как вы оцениваете значение этой эффективности против дополнительной работы?

Answer 1

В нашем приложении мы иногда делаем вызовы RIA, которые возвращали бы до 10 МБ данных, но работали в простейшем смысле, но на самом деле стали кусать нас в зад, когда мы развернули, потому что существуют всевозможные ограничения ввесь веб-сервер <-> HTTP <-> стек браузера, вызвавший проблемы.Я говорю о тайм-аутах, размерах буфера, максимальных размерах запросов и т. Д. Кстати, увеличить время ожидания для вызовов RIA непросто.

Чтобы облегчить эту проблему, мы начали извлекать большие вызовы в RIA вменьшие куски.У нас был бы один запрос на стороне сервера, который при выполнении возвращает все первичные ключи нужных строк (например, 10000 направляющих).Затем на клиенте мы используем RIA для выборки объектов, скажем, порциями по 500, по первичному ключу за один раз.

Наибольший выигрыш это дает нам в пользовательском опыте, потому что мы можем отобразитьиндикатор выполнения для того, сколько данных загружено.Чанкинг также полезен, потому что он делает сервер немного более отзывчивым.Загрузка 10 МБ данных за один вызов занимает исключительно сервер, но загрузка в несколько блоков позволяет распределять ресурсы более плавно.

Надеюсь, это поможет.