Изучение WPF и MVVM

Ну, прежде чем использовать MVVM, я использовал MVC в ASP.NET MVC Framework. Архитектура моделей-контроллеров-контроллеров довольно очевидна, поэтому она помогла мне изменить свое отношение к стандарту ASP.NET и WinForms.

MVVM немного «сложен», чтобы понять, но, как только вы поймете, что WPF отличается от сети (вы, как пользователь отвечают на вид, а не на контроллер), имеет смысл перемещаться от MVC на MVVM. Я предлагаю читать статьи о MVVM на домашней странице Caliburn Project (левый столбец, часть 3. Изучение в МВВМ) - это очень помогло мне.

Относительно приложений WPF (Silverlight), я решительно рекомендую начать строительные приложения прямо на вершине призмы ( композитный WPF ) и / или Кальберн - хотя это может быть запутано с самого начала, все еще это гораздо лучший выбор, чем с ванильным WPF (говорит о практиках, они заставляют вас использовать). Но возьмите это наверняка, что, как только вы закончите свое первое приложение WPF, вы захотите переписать его с нуля. Но вот как это работает, когда вы узнаете новую технологию.

MVVM - это просто шаблон конструкции . Вам не нужно это, если вам не комфортно с WPF. Если вы изучаете WPF, я предлагаю вам сначала завершить книгу, а затем узнать о MVVM. Если вы попробуете изучить обоих, вы бы попытались реализовать MVVM в каждом простом приложении WPF или не понимаю некоторую функцию WPF, что использует MVVM.

P.S: Я пришел к этому выводу, когда я столкнулся с проблемой. Я до сих пор не понимаю, как ViewModel может создать новый вид, если он ничего не знает об этом.

Я столкнулся с подобной ситуацией, и маршрут, который я решил пойти:

• Используйте просмотру для моих представлений, но избегать некоторой чистоты MVVM, как прилагаемое поведение (которые я нахожу тупой и Clunky)
• Использование Magellan MVC Framework , которая соответствует лучшей моей умственной модели о том, как приложения должны вести себя.

Еще в 2002 году, когда я был прямо из колледжа, а рабочих мест было немного и далеко от того момента, когда произошел сбой доткомов, я присоединился к сервисной компании, которая использовала для создания программного обеспечения, адаптированного для их клиентов на Java. Я должен был сидеть в офисе клиента (который был комнатой с раструбами в электрической подстанции, оснащенной переменным током, чтобы держать серверы в рабочем состоянии), делясь стульями/ПК с другими парнями в команде. Другие инженеры (если я могу назвать их инженерами;) в группе, используемой для внесения изменений ad-hoc в исходный код, компиляции файлов и ввода их в производство.

• Невозможно выяснить, кто внес какие изменения.
• Невозможно выяснить, почему были внесены какие-либо изменения.
• Невозможно перейти к предыдущей версии кода, если инженер не «вспомнил», что он изменил.
• Резервное копирование: копирование файлов с производственного сервера, которые были заменены новыми файлами.
• Расположение резервной копии: Главная папка инженера, копирующего файлы на производственный сервер.

Сообщения о сбое производственных серверов из-за неудачных попыток копирования файлов на сервер (пропущенный файл, который нужно скопировать, резервные копии, которые будут потеряны, или неправильные файлы, которые будут скопированы, или не все файлы, которые будут скопированы) были встречены (о нет, не так ли? давайте посмотрим, что произошло; Эй, кто изменил что недавно...? уммм...).

В эти дни, проведя несколько разочаровывающих дней, пытаясь выяснить, кто и что стоит за кодом, я разработал систему для комментариев в списке в заголовке исходного файла, в котором подробно описано следующее:

1. Дата изменения
2. Кто внес изменение
3. Почему изменение было сделано

Два месяца спустя, когда список угрожал оспорить размер исходного кода в файле, у менеджера появилась яркая идея получить систему управления версиями.

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

Инициализаторы сбора (и вывод типа):

var scoobies = new List<Scooby>()
        {
            new Scooby("Buffy"),
            new Scooby("Willow"),
            new Scooby("Xander")

        };

Карты:

List<Scooby>() scoobies = new List<Scooby>();
scoobies.Add(new Scooby("Buffy"));
scoobies.Add(new Scooby("Willow"));
scoobies.Add(new Scooby("Xander"));

Я начал изучать WPF и быстро наткнулся на MVVM - это казалось такой хорошей посадкой, что я застрял с ним. Вероятно, стоит отметить, что существуют некоторые различия в способах реализации MVVM, ключевым из которых является View-first или ViewModel-first. Некоторые, кажется, видят в этом точку Евангелия - у меня недостаточно опыта, чтобы решить, должно ли это быть. Я склонен к виду - первый (таким образом, вид имеет ссылку на ViewModel, и ViewModel имеет ссылку на модель, и нет в другом направлении), но я наткнулся на сценарий, где другой путь был проще.

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

Еще один вопрос:Вы используете определенную рамку для MVVM?