greatoceansoftware Ответов: 2

Как привязать данные к ссылкам, а не к реальным объектам?


Поэтому я возвращаюсь к настольным приложениям после десятилетнего отсутствия в непрограммных ИТ-ролях и учусь C# и WPF. (Не судите меня! Я вижу _reported_ нисходящую тенденцию :-)

Итак, вот моя проблема: у меня есть иерархический родительский объект C#, который я хотел бы использовать в качестве своего избыточного источника данных. Допустим, у него есть ObservableCollection объектов Person. И каждый объект Person в коллекции имеет ObservableCollection тегов (простые объекты, которые имеют имя, описание, цвет). Это делается для того, чтобы пользователь приложения мог "помечать" человека такими вещами, как теги "менеджер" или "сотрудник" (и другие пользовательские теги, которые они создают).

Когда создается отдельный объект тега, я назначаю новый Guid (преобразованный в строку) свойству ID тега. Вместо того чтобы хранить фактический объект тега в коллекции тегов каждого человека (чтобы избежать ненужного раздувания данных), я собирался сохранить значение свойства ID (строку guid) в человеке.Коллекция тегов.

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

Одно из возможных решений, о котором я подумал, - это как только родительский объект будет воссоздан с диска (десериализован), создать временную наблюдаемую коллекцию тегов (фактические объекты тегов вместо строк guid) для каждого человека и привязать к нему. Другие мысли оценил.

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

Что я уже пробовал:

Не беспокойтесь о раздувании данных и просто идите на это.

2 Ответов

Рейтинг:
2

Gerry Schmitz

WPF и UWP (не мертвые) почти эквивалентны. Если вы говорите об "объектах", используйте WPF и UWP .NET framework "классы" для создания экземпляров объектов; эти классы исчисляются тысячами. Может быть, вы думаете о "элементах управления", из которых есть достаточно "примитивов" и наборов инструментов, чтобы построить все, что вы можете себе представить.

В вашем случае вы должны смотреть на списки "пользовательских элементов управления", которые могут напоминать "список форм со списками" и так далее. Вы ограничены только своим воображением, когда дело доходит до реализации пользовательского интерфейса. Если вы поклонник MVVM, когда дело доходит до реализации адаптивного пользовательского интерфейса, то я вам сочувствую.


greatoceansoftware

Спасибо, Джерри. Я думал о пользовательских элементах управления, и это может быть то, где я заканчиваю. Я построил многие из них в свои дни VB/.NET/WinForms. Но привлекательность достижения того же эффекта пользовательского интерфейса с хорошо размещенным DataContext и некоторыми стилями с DataTemplates, кажется, стоит попробовать.

Мне кажется, я обнаружил, что привязка данных действительно зависит от истинно иерархического дерева данных. То есть привязка данных не может эффективно "соединить" два канонических источника данных (независимые коллекции объектов C#, то есть "таблицы") на "внешнем ключе" (то есть ID <guid> В приведенной выше постановке задачи).

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

Рейтинг:
0

greatoceansoftware

Окончательное решение состояло в том, чтобы просто использовать ValueConverters для преобразования идентификатора в другие значения свойств тега и использовать/отображать их. Боль, поскольку каждое свойство требовало своего собственного преобразователя значений. Но так как есть только несколько свойств, и их универсально применимы во всем приложении, стоит приложить усилия.