Есть ли несоответствие между MVVM и возможностью изменять дерево компонентов View?

Question

Прочитав все записи StackOverflow, относящиеся к Model-View-ViewModel архитектуре вместе с большинством доступных ресурсов в сети, я пришел к выводу, что это де-факто стандарт для сборки SOLID Приложения Silverlight.
Я начал планировать свое следующее приложение, используя эту архитектуру. Одним из требований к приложению является создание или изменение структуры визуального компонента. Например, отвечая на взаимодействие с пользователем, я хотел бы программно добавить неизвестное во время компиляции число прямоугольников и эллипсов к определенному холсту или холстам.
Я начал думать о том, чтобы применить шаблон MVVM и подумать, куда должен идти код, отвечающий за присоединение новых компонентов. Я пришел к выводу, что он не принадлежит ни к одному из слоев MVVM, и поэтому невозможно применять эту архитектуру в тех случаях, когда вам приходится манипулировать деревом компонентов во время выполнения.
Есть ли способ по-прежнему использовать Model-View-ViewModel в подобных сценариях или он ограничен только работой с фиксированной структурой компонента View?

Answer 1

Не манипулируйте деревом компонентов. Вместо этого манипулируйте моделью, которая представляет дерево компонентов. Затем сделайте так, чтобы ваше представление связывалось с различными коллекциями и свойствами в этой модели для создания визуальных элементов.

Ниже приведен действительно упрощенный пример. Это просто показывает концепции - пожалуйста, не принимайте это как указание на то, как вы должны учитывать ваш код.

Сначала моя модель:

public abstract class Shape
{
    public double Left { get; set; }
    public double Top { get; set; }
}

public class Rectangle : Shape
{
    public double Width { get; set; }
    public double Height { get; set; }
}

Далее я выставляю коллекцию упомянутых фигур (вы бы использовали другую модель для хранения этой коллекции). Затем я связываю это с моей точки зрения:

<Window x:Name="_root" x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:WpfApplication1"
    Title="Window1" Height="300" Width="300">
    <Window.Resources>
        <DataTemplate DataType="{x:Type local:Rectangle}">
            <Rectangle Width="{Binding Width}" Height="{Binding Height}" Stroke="Black"/>
        </DataTemplate>
    </Window.Resources>
    <ItemsControl DataContext="{Binding ElementName=_root}" ItemsSource="{Binding Shapes}">
        <ItemsControl.ItemsPanel>
            <ItemsPanelTemplate>
                <Canvas/>
            </ItemsPanelTemplate>
        </ItemsControl.ItemsPanel>
        <ItemsControl.ItemContainerStyle>
            <Style>
                <Setter Property="Canvas.Left" Value="{Binding Left}"/>
                <Setter Property="Canvas.Top" Value="{Binding Top}"/>
            </Style>
        </ItemsControl.ItemContainerStyle>
    </ItemsControl>
</Window>

Answer 2

Основная проблема в вашем вопросе - запутывание требований ваших пользователей (манипулирование объектами, которые представлены прямоугольниками и эллипсами (я только догадываюсь)) с деталями реализации (добавление Rectangle s и Ellipse s к Canvas эс).

Опять же, различные обязанности в шаблоне MVVM:

View

Переведите ViewModel в пиксели и преобразуйте входные события в вызовы методов ViewModel.

Это будут фактические компоненты Silverlight (Rectangle, Ellipse, Canvas), привязанные к их DataContext и имеющие несколько очень маленьких обработчиков событий или Command s или что-то еще.

Модель

Хранение данных и бизнес-логики в зависимости от предметной области.

Это представляет "математические" прямоугольники и эллипсы, которые рисуют ваши пользователи.

ViewModel

Уточните модель ориентированным на пользовательский интерфейс и часто зависящим от конкретного случая образом.

Здесь вы храните информацию о переходных процессах, таких как «текущий выбранный объект», которые относятся к конкретному представлению, но не являются атрибутами концепции базовой модели.

Прочтите мой блог для подробнее о моих взглядах на MVVM .