Как реализовать Ведущие Детали CRUD о том же экране под MVVM
У меня есть MVVM (Призма) приложение, что я должен реализовать ведущий экран деталей, где ведущее устройство является listview, и детали отображен рядом с ним. Только для чтения кажется достаточно легким (еще не сделали этого, но у меня есть голова вокруг WPF, связывающего), но редактируйте/добавляйте, смущает меня.
Как я делаю его так, ведущее устройство не обновляется до деталей сохраняется? Как я делаю его так, Вы не можете изменить текущий выбор ведущего устройства, в то время как в редактируют/добавляют режим?
Я гуглил много, но не нашел мясистых примеров этого.
Спасибо.
PS: Это представление является дочерним представлением о большем экране. Поэтому я хочу и ведущее устройство и деталь вместе.
2 ответа
Спасибо за ответ. Сейчас перечитал свое сообщение, вижу, что оно довольно расплывчатое. У меня есть экран, на котором редактируется объект, содержащий несколько списков других дочерних объектов. Я реализовал их как разные вкладки в элементе управления вкладками. Одна из этих вкладок редактирует комментарии, поэтому я хотел отобразить список комментариев с панелью редактирования для текущего выбора рядом со списком. Затем пользователь может использовать кнопки добавления, редактирования или удаления для обновления списка. Я хотел сделать это чисто (иш) способом MVVM.
Я придумал следующий дизайн, который, кажется, работает с минимальными хитростями.
View включает в себя список дочерних объектов просто как ListView, привязанный к наблюдаемой коллекции в ViewModel. Я включил буфер дочернего объекта - он используется для буферизации изменений до тех пор, пока они не будут готовы к сохранению обратно в список (или удалению).
View также включает панель редактирования, привязанную к объекту буфера в ViewModel. Буфер обновляется всякий раз, когда текущий выбор представления списка изменяется с использованием глубокой копии. Я попытался использовать привязку данных к свойству Selecteditem, но набор так и не был вызван, поэтому был добавлен небольшой метод кода программной части для принудительного обновления свойства при изменении выбора.
Представление списка и представление редактирования являются взаимоисключающими. Теоретически вы можете скрыть отключенный, возможно, используя откидной экран. Как правило, для моего приложения лучше, чтобы оба были видны одновременно, поскольку панель редактирования может отображать дополнительную информацию, не отображаемую в представлении списка.Выбор того, какая панель включена, контролируется привязкой IsEnabled к свойству ViewModel, например IsEditCommentMode.
Необходимо добавить команды для управления списком, это New, Edit и Delete. Обратите внимание, что при добавлении и редактировании буфер настраивается, а затем для параметра IsEditCommentMode устанавливается значение true. Эти команды управления списком доступны только в том случае, если IsEditCommentMode имеет значение false. На панели редактирования реализованы команды Сохранить и Отменить, они доступны, только если IsEditCommentMode имеет значение true. Когда выполняется сохранение, оно должно копировать из буфера в список (добавлять или обновлять) и запускать уведомление об изменении. Наконец, он должен установить IsEditCommentMode в false.
Все это работает хорошо и, похоже, не нарушает никаких принципов MVVM (по моему скромному, но часто ошибочному мнению).
Вы, конечно, можете это сделать, хотя, на мой взгляд, такой дизайн пользовательского интерфейса не может использовать всю мощь WPF. Старые пользовательские интерфейсы WinForms обычно не обновляли большую часть приложения до тех пор, пока данные не были сохранены на SQL Server (или где-то еще), потому что у них не было реальных бизнес-объектов и мощной системы привязки, такой как WPF. Попытка скопировать ограничения WinForms в WPF кажется мне шагом назад. Почему бы не показывать последние данные везде, где они видны в пользовательском интерфейсе, в том числе в главном представлении? Кроме того, почему бы не разрешить пользователю редактировать несколько элементов перед сохранением, например, пометить любой отредактированный, но несохраненный элемент анимированным маркером в главном представлении? Объедините их с общей отменой, и вы получите лучший дизайн и более интуитивно понятный для пользователя.
Однако, если ваши бизнес-требования делают это абсолютно необходимым, вот как это сделать:
Предотвращение видимости изменений данных за пределами детали до тех пор, пока она не будет сохранена.
При входе в ваш «режим редактирования / добавления» , сделайте копию объектов данных и установите DataContext подробного представления на копию, а не на живой объект.Когда данные «сохранены», скопируйте данные из теневой копии обратно в живой объект и верните контекст DataContext детального представления туда, где он должен быть.
Предотвращение изменения текущего выбора мастера в режиме редактирования / добавления
Две возможности:
В режиме редактирования / добавления изменить основной вид, чтобы запретить проверку нажатия мыши или фокус клавиатуры
При редактировании / добавлении начинается режим, захватите «текущий выбор», затем добавьте обработчик событий, который следит за изменениями «текущего выбора» и немедленно изменяет выбор обратно на то, что было. Когда режим редактирования / добавления завершится, удалите обработчик. Этот обработчик может быть удобно закодирован с использованием лямбда-выражения и замыкания локальной переменной для сохранения текущего выбора.