WPF: действительно ли привязка данных значительна для модальных диалоговых окон?
С Ctrl + Сдвиг + L можно открыть "key assist", где можно найти все ярлыки.
4 ответа
Я уже сталкивался с подобными требованиями раньше и предпочитаю два варианта, оба с использованием привязки данных.
В первом варианте мы клонируем объект и связываемся с клоном. Когда пользователь нажимает ОК, клонированный объект заменяется реальным объектом. Это в основном полезно при редактировании одного объекта за раз, и на объект не ссылаются напрямую другие объекты. Если на него есть ссылка, то вместо этого вы можете скопировать значения из вашего клона в свой оригинал, чтобы ссылки остались нетронутыми. Это экономит работу, потому что в редакторах не требуется дополнительной работы, в лучшем случае вы должны определить для своего объекта 2 метода, клонирование и, возможно, метод Apply для копирования значений из клона.
Второй вариант мы привязываем к оригиналу объект, но мы сохраняем исходные значения в нашем диалоге редактирования, либо в локальных полях, либо во временном объекте данных. Когда пользователь нажимает ОК, ничего особенного не должно происходить, но когда пользователь нажимает «Отмена», мы возвращаем значения. Это в основном полезно, когда вы редактируете только несколько простых свойств в диалоговом окне.
Я предпочитаю решения для привязки данных, потому что они не загрязняют диалоговые окна редактирования логикой применения / отмены, которая, если реализована в редакторах, очень зависит от ваших элементов управления XAML: можно переименовать, поле со списком можно заменить текстовым полем и т. д., все это повлияет на код, который вручную обрабатывает данные из элементов управления.
Методы Clone / Apply должны применяться только к вашим бизнес-объектам, которые теоретически более стабильны, чем ваши редакторы пользовательского интерфейса. Даже если XAML изменится, в большинстве случаев ваши привязки могут остаться прежними.
Один из вариантов - реализовать в бизнес-объекте IEditableObject .
- Перед отображением окна вызовите BeginEdit для своего объекта
- Если пользователь нажимает кнопку ОК, вызывает EndEdit
- Если пользователь нажимает кнопку «Отмена», вызовите CancelEdit
IEditableObject обычно используется в сценариях сетки данных, но он также хорошо работает и в описанном вами случае. Кроме того, если ваш пользовательский интерфейс когда-либо изменится, чтобы разрешить встроенное редактирование в DataGrid, вам не придется изменять свой бизнес-объект.
Вы можете использовать привязку данных для одностороннего обновления графического интерфейса пользователя, но если вы хотите отложить обновление бизнес-модели только после нажатия OK, лучше сделать это в коде. Привязка данных вообще в этом случае может быть ненужной.
Возьмем, например, FolderBrowserDialog . Вы можете установить начальное значение SelectedPath перед вызовом ShowDialog () , но вы ждете, пока диалоговое окно вернется с DialogResult.OK , прежде чем обрабатывать данные . Аналогичный подход должен работать и в вашей ситуации.
Обработчик загрузки формы Просмотрите коллекцию Bindings и установите для каждого DataSourceUpdateMode значение Never. В обработчике OK установлено противоположное (DataSourceUpdateMode.OnValidation) и вызовите форму ValidateChildren
, если привязка выполняется через графический интерфейс, появится новый член формы класса BindingSource Это немного упрощает - привязки, доступные CurrencyManager.Bindings, и BindingSource.EndEdit могут использоваться вместо ValidateChildren.