Глен Блок (см. Выше) упоминает, что общий подход заключается в разработке решения MVVM с использованием DataContext в качестве места, где вы можете «разрешить» свою модель представления в представлении. . Затем вы можете использовать расширения дизайна из Expression Blend 2008 (обратите внимание, что вам не нужно использовать инструменты проектирования Expression Blend, чтобы воспользоваться этим). Например:
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
mc:Ignorable="d"
d:DataContext="{d:DesignInstance Type=local:MyViewModelMock, IsDesignTimeCreatable=True}"
На ваш взгляд, у вас может быть метод получения свойства, который приводит ваш DataContext к ожидаемому типу (просто для того, чтобы упростить использование кода программной части).
private IMyViewModel ViewModel { get { return (IMyViewModel) DataContext; } }
Не забудьте использовать интерфейс, чтобы ваши представления было легче тестировать или чтобы помочь вам внедрить различные реализации среды выполнения.
В общем, вы не должны разрешать вещи из контейнера повсюду в вашем решении. На самом деле считается плохой практикой передавать свой контейнер в каждый конструктор или делать его глобально доступным. (Вы должны найти обсуждение того, почему стратегии "Service Locator" представляют собой "Anti-Pattern").
Создайте конструктор общедоступного представления с явными зависимостями, которые может разрешить контейнер (например, Prism Unity или MEF).
При необходимости вы также можете создать внутренний конструктор по умолчанию, чтобы создать имитацию вашей модели представления (или настоящую, если на то пошло). Это защищает от непреднамеренного использования этого «конструктора дизайна» извне (в вашей «оболочке» или где-либо еще). В ваших тестовых проектах также можно использовать такие конструкторы с помощью атрибута InternalsVisibleToAttribute в AssemblyInfo. Но, конечно, обычно в этом нет необходимости, поскольку вы все равно можете внедрять свои макеты, используя конструкторы полных зависимостей, а также потому, что большинство ваших тестов должны быть сосредоточены в первую очередь на ViewModel. В идеале любой код в представлении должен быть довольно тривиальным. (Если ваше представление требует тщательного тестирования, вы можете спросить себя, почему!)
Глен также упоминает, что вы можете вставлять представления в модели представления или модели представления в представления. Я предпочитаю последнее, потому что есть совершенно хорошие методы для разделения всего (использование декларативного связывания, команд, агрегации событий, шаблонов посредника и т. Д.). Модель просмотра - это то место, где будет выполняться вся тяжелая работа по координации основной бизнес-логики. Если все необходимые "привязки" предусмотрены моделью представления, ей действительно не нужно знать НИЧЕГО о представлении ( который в большинстве случаев можно подключить к нему декларативно в XAML).
Если мы сделаем модель представления независимой от источника взаимодействия с пользователем, это значительно упростит тестирование (желательно сначала). И это также означает, что вы можете легко подключить ЛЮБОЕ представление (WPF, Silverlight, ASP.NET, консоль и т. Д.). Фактически, чтобы гарантировать, что соответствующее разделение было достигнуто, мы можем спросить себя, может ли архитектура «MVM» (Модель-ViewModel) работать в контексте, скажем, службы рабочего процесса. Если задуматься, большинство ваших модульных тестов, вероятно, будут построены на этой предпосылке.
person
Ben Stabile
schedule
29.10.2013
