Лучшая практика для получения данных для DataGrid из веб-службы

Question

У меня есть WPF DataGrid, который получает его данные из веб-службы.Конечный пользователь имеет возможность настроить видимые столбцы в DataGrid.

1-й подход:

Я получаю эти данные в xml и после преобразования xml в dataTable и передаю их как ItemsSourceдля DataGrid.

2-й подход:

Также я могу получить эти данные, такие как массив классов из службы (например, Customer [])

Проблема:

Я использую 1-й подход с дополнительными шагами, чтобы не получать избыточные данные от службы.При втором подходе, если пользователь видит только два столбца в DataGrid (один столбец для одного свойства в классе), он получает весь класс со всеми заполненными им свойствами (избыточные данные).при первом подходе он получает только данные xml, которые будут видны в сетке данных в пользовательском интерфейсе.

Но я использую подход MVMM в своем проекте и не хочу использовать подход xml и dataTable.Я думаю, что я должен использовать второй подход, но в этом случае я получаю избыточные данные

Answer 1

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

Если вышеприведенное - единственное, что мешает вам использовать второй подход, то C # v4.0 имеет функцию Именованные и дополнительные аргументы . Который работает как

Console.WriteLine(Calculate(weight: 123, height: 64));

, даже если фактическое Calculate() имеет 99 аргументов, с любым порядком .

Обратите внимание, я предполагаю, что под избыточным вы подразумеваете нежелательные данные.

Answer 2

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

В вашем конкретном случае,

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

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

Чтобы выбрать правильный подход, вы должны рассмотреть и взвесить нефункциональные требования, такие как производительность, расширяемость, управляемость и т. Д.

Answer 3

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

Проверено ли у вас проблемы с производительностью при втором подходе?