Почему я должен использовать MVVM в приложении Silverlight? - PullRequest
9 голосов
/ 07 января 2011

Я хочу знать, почему мы должны использовать MVVM для реализации приложения Silverlight. В чем его преимущества?

Мы не проводим модульный тест для ViewModel, поэтому я хочу другие причины.

Ниже приведены мои вопросы о некоторых преимуществах, которые обычно говорят люди:

1.Слабосвязанная: когда мы используем MVVM, представление полагается на ViewModel, но не на представление, почему оно слабо связано?

2.Если я предоставляю открытые методы в коде, они также могут обеспечить возможность повторного использования.

Ответы [ 8 ]

4 голосов
/ 07 января 2011

Мы не проводим модульное тестирование для ViewModel,

С MVVM речь идет не только о модульном тестировании ViewModel.В идеале ваша ВМ должна быть очень тонкой и иметь только свойства, необходимые для просмотра.Таким образом, нет необходимости проверять виртуальную машину.

Но без ВМ, как вы проводите функциональное тестирование на разных уровнях?В Silverlight для облегчения тестирования вы должны использовать команды, а не писать код в файлах с выделенным кодом.Это позволяет имитировать нажатие кнопки и другие события GUI во время модульного тестирования.Используя шаблон MVVM вместе с командами, вы можете протестировать весь код C # (не xaml), вплоть до пользовательского интерфейса (конвертер, виртуальные машины и т. Д.).

Если я предоставлю публичные методы в выделенном коде, они также могут обеспечить возможность повторного использования.

Не вдаваясь в детали того, насколько это плохой дизайн, я хочуспросить вас, как это обеспечивает возможность повторного использования?Если вы создаете пользовательский элемент управления, то класс code-behind является элементом управления?Вы хотите создать экземпляры своего контроля и использовать их?Это все равно что сказать, что для чего нужны методы-члены, мы можем просто создавать открытые статические методы и получать к ним доступ.Я твердо убежден, что если мы не хотим использовать автоматическое связывание, предоставляемое WPF / Silverlight, то лучше НЕ использовать эти технологии.А чтобы использовать все возможности связывания, MVVM необходим.

почему он слабо связан?

ВМ - это очень важная часть вашего взгляда.Это не отделено от зрения.Как я уже сказал, ваша виртуальная машина должна быть как можно более тонкой и иметь только открытые свойства, необходимые вашему представлению.Ваша бизнес-логика будет отделена от вашего представления (и виртуальной машины).

4 голосов
/ 07 января 2011

Что ж, тестируемая модулем модель представления является значительным преимуществом, так что вы упустите это преимущество. По поводу двух других:

Слабосвязанная

Да, представление зависит от модели представления. Они должны быть связаны каким-либо образом для выполнения функции приложения. В результате они не могут быть расцеплены. Единственный выбор - тесно или слабо связанный или где-то посередине. С MVVM ваша модель представления взаимодействует с вашим представлением очень ограниченным образом: в основном только объекты, свойства и команды. Сравните это с выполнением всего в коде, где представление и его управление по сути неразделимы.

Повторное использование

Если какой-либо код в вашем коде позади достаточно многократно использовать, чтобы заслужить его публичность, его можно извлечь из кода сзади и поместить в класс общего назначения. Проблема в том, что то, что осталось после этого, не может быть использовано повторно.

Если вы не хотите углубляться в глубокое погружение MVVM, вы можете получить некоторые из преимуществ MVVM, сосредоточившись на привязке данных. Изучив преимущества привязки данных, вы можете пересмотреть другие преимущества MVVM.

1 голос
/ 15 ноября 2011

Без MVVM код вашего приложения Silverlight очень скоро превратится в неуправляемый беспорядок

1 голос
/ 11 января 2011

Я был одним из первых пользователей WPF и могу рассказать вам, что заставило меня выбрать MVVM (и это более или менее относится и к Silverlight). Для проекта, над которым я работал, мне пришлось создать экран, который позволял бы пользователям подписываться на уведомления в системе. Это был трехэтапный процесс:

  1. Пользователь должен был найти элемент, о котором он хотел бы получить уведомление
  2. Они должны были выбрать пункт и заполнить дополнительные параметры, касающиеся подписки
  3. Система должна предоставить сводку и позволить пользователю подтвердить или изменить подписку.

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

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

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

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

1 голос
/ 07 января 2011

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

1 Если несколько элементов управления связаны с одним свойством.

MVVM:

<TextBlock x:Name="text1" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/>
<TextBlock x:Name="text2" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/>

Я могу быстро добавить аналогичный элемент управления илиудалить существующий элемент управления.

Сравнить с выделенным кодом:

public string IsSomePropertyTrue
{
    set
    {
        //...
        text1.Visibility = value;
        text2.Visibility = value; 
    }
}

2 Вместо мультиконвертера

public Brush StateColor {get {if (this.State)== State.Edited && this.IsPriority) return new SolidColorBrush (Color.FromArgb (255, 0, 255, 0));// ...}}

<sdk:DataGridTemplateColumn.CellTemplate>
    <DataTemplate>
        <TextBlock Background="{Binding StateColor}" Text="{Binding State}"/>
    </DataTemplate>
</sdk:DataGridTemplateColumn.CellTemplate>

3 В качестве модели элемента в элементах управления, таких как ListBox или DataGrid.Например, если я хочу создать список элементов с кнопкой удаления рядом с каждым элементом, я создам элемент управления ItemView и класс ItemViewModel.

<ItemsControl ItemsSource="{Binding SomeItems}">
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <view:ItemView DataContext="{Binding}"/>
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ItemsControl>

4 Копирование данных из одного представления в другое:

public JournalEntryViewModel(SalesOrderViewModel vm) {}

5 ViewModel может наследовать CLR-классы и реализовывать интерфейсы (INotifyPropertyChanged или INotifyDataErrorInfo).

Также я использую MVVM для замены событий командами или свойствами.А использование ViewModels заставляет вызывать свойства по понятным именам.

1 голос
/ 07 января 2011

Я думаю, что это один из лучших доступных ресурсов, на случай, если вы захотите использовать и сопоставить использование MVVM против ЛЮБОГО другого шаблона или без шаблона.

http://karlshifflett.wordpress.com/2010/11/07/in-the-box-ndash-mvvm-training/

0 голосов
/ 10 января 2011

Разлука с людьми.Разделение концернов.

Забудьте юнит-тестирование (мне это нравится; но здесь дело не в этом).Забудьте о возможности повторного использования (вы действительно повторно используете модели представлений? Нет, давайте будем реальными здесь).

Речь идет о разделении проблем и размещении кода и логики там, где они есть.Вся идея - ремонтопригодность;возможность вносить изменения в код по мере его развития с течением времени, не нарушая другие вещи и не превращая все это в большую кучу спагетти.

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

0 голосов
/ 07 января 2011

Что также интересно в MVVM - это динамическое автоматическое связывание.

Представьте, что ваша модель представления имеет такие свойства: bool IsFirstNameVisible, bool IsFirstNameEnabled, строка FirstName, двойное FirstNameWidth и т. Д.

В вашем XAML-файле вы определяете TextBox с помощью x: Name = "FirstName" и вызываете динамическое связывание MVVM. Он проверяет ваш класс модели представления с помощью отражения, просматривает, какие свойства вы определили, и динамически связывает их с аналогичными свойствами элемента управления с тем же именем, применяя преобразователи значений при необходимости.

В этом случае вы получите очень чистый XAML без выражений привязки данных длиной в километр и преобразователей.

Это то, что делает моя библиотека MVVM.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...