Почему события и команды в MVVM так не поддерживаются WPF / Visual Studio?
Я использую этот код, и он всегда работал:
/// <summary>
/// Turn a string into a CSV cell output
/// </summary>
/// <param name="str">String to output</param>
/// <returns>The CSV cell formatted string</returns>
public static string StringToCSVCell(string str)
{
bool mustQuote = (str.Contains(",") || str.Contains("\"") || str.Contains("\r") || str.Contains("\n"));
if (mustQuote)
{
StringBuilder sb = new StringBuilder();
sb.Append("\"");
foreach (char nextChar in str)
{
sb.Append(nextChar);
if (nextChar == '"')
sb.Append("\"");
}
sb.Append("\"");
return sb.ToString();
}
return str;
}
5 ответов
По словам Джоша Смит статья о MVVM, она была представлена миру в октябре 2005 года в блоге Джона Госсмана .
С тех пор я бы сказал, что потребовалось еще 2-3 года, чтобы WPF / MVVM действительно взлетел и был принят сообществом, но было уже слишком поздно модифицировать WPF для поддержки проблем с MVVM. Как и я'
Взгляните в этом шаблоне проекта MVVM для VisualStudio.
http://blogs.msdn.com/llobo/archive/2009/05/01/download-mv-vm-project-template-toolkit.aspx
С этим шаблоном вы получаете различные классы DelegateCommand, которые удовлетворяют различные потребности в ICommands, и класс CommandReference, который помогает с привязкой клавиш.
Это хорошее начало ...
Becuase MVVM был "изобретен" после WPF ... поэтому большие части головоломки MVVM не являются частью платформы WPF.
Не только это, но и сам MVVM был объявлен «шаблоном» еще до того, как он был даже испытан / применен в реальном мире. Что является полной противоположностью тому, что такое шаблоны - они обычно обнаруживаются и документируются после многих лет успешного использования множеством разных людей.
Один парень придумывает выкройку, а не выкройку.
Вы правы насчет сложности команд. Я стараюсь следовать схеме M-V-VM как можно ближе, но я не могу оправдать сложные обходные пути только для обработки простого пользовательского события.
На мой взгляд, можно обрабатывать пользовательское событие в представлении, если это значительно упрощает ваш код. Если вы обрабатываете пользовательское событие в представлении, то код-behind вашего представления должен немедленно вызвать метод на ViewModel. Таким образом, вы сохраняете свою логику во ViewModel... у вас просто есть небольшой код (обработчик событий) в View. Я знаю, что пуристы M-V-VM считают, что не должно быть никакого кода в code-behind представления, но иногда просто имеет смысл разрешить некоторый простой код, например, обработчик событий. Помните, что другим людям, возможно, придется читать/изменять ваш код в будущем, и гораздо легче понять обработчик события, чем команду делегата.
Рад слышать, что я не единственный, кто считает, что существующие командные реализации излишни . Привязка данных, естественно, хорошо поддерживается, но я несколько недель бился головой, пытаясь понять привязки команд для вещей, отличных от кнопок и элементов, которые от нее наследуются.
Спасибо, что разместили этот вопрос. Я думаю, что с этого момента я собираюсь обрабатывать все события на уровне представления с перенаправлением на функции модели представления. Думаю, именно так они обучали основам MVVM в одном из двухдневных курсов Microsoft XAMLFest. Достаточно хорошо для меня!