Возврат анонимного типа через службу WCF RIA или обработку динамичности

Question

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

Product
   |
   |-Orders
       |        
       |- and so on

Дело в том, что у нас есть определенная таблица в базе данных, ее схема иподробности следующие:

Имя таблицы PanesInfo

ID  PaneName  TableName  TableColomn     Level  Type
1   PaneOne    Products   ProductID        1
2   PaneOne    Products   ProductName      1
3   PaneOne     Orders    OrderID          2
4   PaneOne     Orders    OrderName        2
5   PaneONE     Orders    ORderRef         2

В равной степени они будут иметь определенный уровень 2, и эта таблица будет содержать информацию для всех панелей, теперь пользователь должен будет сначала запросить эту таблицу дляполучить информацию о том, что должно быть показано в таблице данных на первом уровне УРОВЕНЬ ВТОРОЙ и 3-м уровне и т. д. и т. д. (отношения родитель-ребенок), здесь также будет упомянуто ассоциация между этими уровнями. Я не уверен, как, поскольку это имеетчтобы обсудить это с клиентом, сейчас мы испробовали множество решений (например, разбор xml), пожалуйста, предложите решение, которое будет иметь меньше итераций на стороне сервера, так как эта база данных очень тяжелая.

Answer 1

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

Answer 2

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

Ваш первый запрос должен быть только для получения продуктов. Когда Продукты прибывают на клиента, возьмите первый и отправьте запрос в БД для получения дополнительной информации об этом Продукте. Затем поднимите свои свойства для интерфейса, чтобы обновить интерфейс. Пока сетка продуктов обновляется, запрос БД отключен, чтобы собрать больше информации только по этому одному продукту (например, Заказы). Когда он (Заказы) прибудет, он заполнит другие сетки. Для пользователя, скорее всего, он будет выглядеть так, как будто все данные поступят в одно и то же время (привязка сетки продукта занимает время ..)

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

Если вы запрашиваете данные более одного раза, RIA обрабатывает это путем объединения данных, только что полученных из БД, в модель на стороне клиента. Режим по умолчанию не отменяет данные, которые были изменены на стороне клиента. Он также будет игнорировать данные, если данные уже существуют на стороне клиента - это означает, что вы произвели отключение БД даром.

Помните, что это не клиентский сервер. Вы транспортируете данные с сервера на клиент. Существует модель на стороне клиента, а также модель клиент-сервер на стороне сервера (это часть EF). Службы RIA не только управляют передачей данных, но также предоставляют модель на стороне клиента, идентичную модели на стороне сервера.

НТН, Ричард