Блог

У меня есть приложение WPF, которое инкапсулирует редактирование дюжины или около того файлов конфигурации xml в одном месте, так что инженеру по развертыванию не нужно знать, где что-то может быть изменено, а где нет. На данный момент каждая конфигурация представлена как отдельный объект с логикой обновления различных элементов пользовательского интерфейса в виде стандартных функций get и set.

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

Я просматривал привязку данных WPF, и хотя она отлично подходит для чтения и записи XML и отображения в различных элементах управления приложения, у меня возникли проблемы с определением того, как именно я бы реализовал часть копирования. Не пойду ли я по неверному пути, используя привязку данных вообще?

Ответ на вопрос «Должен ли я использовать привязку данных в WPF?» почти неизменно «Да». Реальный вопрос звучит примерно так: «Для чего мне следует использовать привязку данных WPF?»

Звучит так, как будто архитектура вашего приложения в настоящее время:

 XML <--> Object Model <--> UI Controls
  

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

Если методы, реализованные в настоящее время в вашей объектной модели, вносят изменения в свойства объектов, которые необходимо перенести в пользовательский интерфейс, все может немного усложниться. Например, вы можете обнаружить, что хотите создать Command объекты, чтобы предоставить доступ к этим методам в пользовательском интерфейсе, а затем необходимо реализовать некоторый механизм для инициирования PropertyChanged событий после того, как методы изменяют свойства объектов. В зависимости от общей архитектуры вашего приложения вы можете не захотеть интегрировать объекты WPF (например, команды) или реализовывать уведомления об изменении свойств в вашей объектной модели.

Это вводит вас на территорию шаблона MVVM («viewmodel layer», на который ссылается Джо Уайт), который представляет собой способ инкапсуляции команд и уведомлений об изменении свойств (и других материалов, необходимых пользовательскому интерфейсу WPF) без необходимости изменять базовую объектную модель. Все в порядке. При первом выполнении это немного утомительно, главным образом потому, что информация, которую вы найдете, когда начнете ее изучать, покажет вам решения проблем, которых у вас, возможно, нет (или, возможно, еще нет). Но на самом деле это не так уж плохо.

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

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

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