Макет приложения WPF

Question

В настоящее время мы разрабатываем новый интерфейс конфигурации для нашего приложения.Чтобы приложение работало в браузере как XBAP, мы не хотим использовать модальные диалоги.Я не хочу обсуждать сам дизайн пользовательского интерфейса, но я хотел бы задать технический вопрос, если наш подход хорош с технической стороны.Большинство из них являются новыми для WPF в деталях, но мы знакомы с шаблоном MVVM, и одна из наших основных целей состоит в том, чтобы отделить большую часть кода от GUI и в основном использовать xmal для определения UI.

Хорошо, теперь к нашему эскизу.

«Главное меню»: должно быть какое-то Outlook, похожее на древовидную структуру, чтобы выбрать раздел конфигурации, который пользователь хочет редактировать

«Контекстно-зависимое меню»": следует ли меню в зависимости от элемента, выбранного в" главном меню ", например, панели ленты.Это обеспечивает такие функции, как «добавить новую запись» или «удалить запись», но также имеет функцию в масштабе приложения, такую ​​как «загрузить конфигурационный файл»

«Контекст»: должен быть данными позади записи, выбранной в «главном меню»"например, сетка записей конфигурации в выбранной категории.

Хорошо, в действительности концепция заключалась в том, чтобы страница разбивалась на два фрейма, а одна страница" Mainmenue "загружалась слева, а вторая - справа.Правый обменивается, когда пользователь выбирает что-то в меню.Но не так сложно создавать новое представление контекста, поскольку мы не можем унаследовать различия от xaml ui.Я попробовал обходной путь, описанный здесь 2 , но это не очень хорошо.И мы не хотим определять наш пользовательский интерфейс в C #, что было бы еще одним решением этой проблемы.

Теперь мы создали новый эскиз, чтобы реорганизовать наш макет.Теперь мы хотим разделить главную страницу на три кадра: один для «главного меню», один для «контекста» и один для «контекстно-зависимого меню».Фактически, каждое контекстное представление имеет свою собственную ViewModel, которую мы подумали о том, чтобы каждая Viewmodel имела свойство типа «записей меню» и связывала его с «контекстно-зависимым меню», которое должно отображать меню для контекста.И если функция приложения была запрограммирована только один раз.

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

Answer 1

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

Лично я думаю, что вы должны сесть с некоторыми из ваших пользователей и показать им несколько макетов экрана. Я работаю над дизайном пользовательского интерфейса уже несколько лет, и я могу вам сказать, что вы можете сэкономить огромное количество времени, демонстрируя своим пользователям концепцию, прежде чем даже думать о внедрении. Также, возможно, стоит провести небольшое исследование UX, чтобы увидеть, как часто будет использоваться каждая часть вашего UI. Например, MainMenue должен постоянно присутствовать на экране? Может ли он быть закреплен справа и отображаться только тогда, когда пользователь наводит на него курсор?

С точки зрения моделирования ваши ViewModels помнят, что ваши ViewModel могут содержать вложенные ViewModel, и каждая ViewModel должна нести одну ответственность (например, в соответствии с принципом единой ответственности), возможно, каждая запись в вашей сетке связана с собственным экземпляром GridRecordViewModel и GridRecordViewModel содержатся в коллекции ObservableCollection в AllGridRecordsViewModel.