MVVM - несколько рабочих областей в рабочей области, кажется, не имеют смысла

Question

Итак, как вы выводите на экран комплексные агрегированные ViewModels , чьи модели связаны друг с другом?

НЕТ, ученик wpf никогда не говорил об этом, угадайте, почему это невозможно ...

Как вы думаете, это правда?

Не понимаешь меня?

Посмотрите: A CustomerViewModel имеет много OrderViewModel и много ProductViewModel .

У вас есть 3 рабочих пространства для ввода новых данных для всех 3 ViewModels И у вас есть 3 списка / combobo / datagrid для множественного выбора коллекций типа => customerVM s, orderVM s и productVM`s.

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

EDIT:

У вас в MVVM есть Коллекция типа WorkSpace. Каждый ViewModel может быть рабочим пространством, потому что он является производным от класса WorkSpace. Коллекция Workspaces связана с примером ItemsSource afair josh smith.

Заявление : Я хочу использовать зрелые пользовательские интерфейсы форм goold без закрываемых моделей представления ... Проблема : MVVM может работать только с рабочими пространствами (закрываемый не имеет значения ...), потому что экземпляр CustomerviewModel должен быть уже создан, а затем добавлен в коллекцию рабочих пространств, привязанную к itemsControl и датированную в зависимости от типа данных.

Если бы у меня не было рабочих областей, в которых хранятся мои экземпляры ViewModel, я бы не смог их датировать, потому что ViewModel в MVVM принимает модель в качестве параметра конструктора. DataTemplating UserControl с DataType CustomerViewModel вызовет исключение в XAML!

Теперь посмотрите на мой пользовательский интерфейс, который я хочу иметь: у меня нет рабочих пространств, но 3 ViewModels = 3 UserControls с датой, означающей 3 раза большой взрыв ...

Теперь вы понимаете, почему я не люблю MVVM? Это плохо продумано, и я ищу решение ...

Конечно, я мог бы поместить свои ViewModels или DataFormulars в ObservableCollection, но я не хочу, чтобы они были связаны с ItemsControl. Я хочу, чтобы эти 3 UserControl имели определенную позицию в моем макете. с ItemsControl у вас есть тупая очередь, где новый Dataformular просто добавляется и переносится, если он не помещается в существующее пространство. Это все мусор дизайн макета / плохой интерфейс.

Вы меня понимаете?

Answer 1

Вы можете легко иметь несколько элементов управления в окне, каждый из которых привязан к отдельной модели представления. Для координации между виртуальными машинами типичный подход заключается в свободном соединении различных компонентов вместе с помощью передачи сообщений. Например, ваша Customer ViewModel может отправить сообщение о том, что вы выбрали ордер, а затем ваш OrderViewModel (возможно, визуализированный как элемент управления в части вашего главного окна) увидит сообщение и изменит отображаемый ордер.

Вы можете сделать нечто подобное с общим классом обслуживания, который предоставляет интерфейс, который вы вводите в каждую из ваших виртуальных машин. Затем вы можете связать свойства этого общего интерфейса, чтобы позволить виртуальным машинам взаимодействовать, почти так же, как с сообщениями. Я использовал нечто похожее на это, чтобы представить концепцию «SelectedObject», в которой можно выбрать широкий диапазон различных типов объектов, и разные виртуальные машины в моем приложении могут по-разному визуализировать это. Например, на вашем примере, если Продукт стал SelectedObject, у вас может быть панель подробностей, которая теперь отображает Продукт с использованием некоторого стандартного ProductDataTemplate, и, возможно, другая панель (отображающая Заказ) изменит SelectedItem в списке Продуктов. Вы можете легко иметь несколько «рабочих пространств», и все они будут синхронизированы друг с другом благодаря набору свойств или сообщений, которые виртуальные машины используют для совместной работы.