Действительно ли MVVM бессмыслен? [закрытый]

Я решаю проблему с диалогами с помощью жульничества. My MainWindow реализует интерфейс IWindowServices, который предоставляет все диалоговые окна, зависящие от приложения. Затем мои другие ViewModels могут импортировать интерфейс служб (я использую MEF, но вы легко можете просто передать интерфейс через конструкторы вручную) и использовать его для выполнения того, что необходимо. Например, вот как выглядит интерфейс моего небольшого служебного приложения:

//Wrapper interface for dialog functionality to allow for mocking during tests
public interface IWindowServices
{
    bool ExecuteNewProject(NewProjectViewModel model);

    bool ExecuteImportSymbols(ImportSymbolsViewModel model);

    bool ExecuteOpenDialog(OpenFileDialog dialog);

    bool ExecuteSaveDialog(SaveFileDialog dialog);

    bool ExecuteWarningConfirmation(string text, string caption);

    void ExitApplication();
}

Это объединяет все исполнения диалогов в одном месте, и его можно легко отключить для модульного тестирования. Я следую шаблону, согласно которому клиент диалога должен создать соответствующую ViewModel, которую затем можно настроить по мере необходимости. Блокирует вызов Execute, после чего клиент может просмотреть содержимое ViewModel, чтобы увидеть результаты диалога.

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

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

• Представление содержит определенные элементы управления графического интерфейса пользователя и определяет внешний вид пользовательского интерфейса.
• ViewModel представляет состояние и поведение презентации.
• Модель может быть бизнес-объектом уровня домена или службой, предоставляющей необходимые данные.

Но отсутствует:

• Кто создает ViewModels?
• Кто отвечает за рабочий процесс приложения?
• Кто является посредником между ViewModels, когда им нужно взаимодействовать друг с другом?

Мой подход состоит в том, чтобы представить (Сценарий использования) Контроллер , который отвечает за недостающие точки. Как это работает, можно увидеть в примерах приложений WPF Application Framework (WAF) .

Трудно заставить это работать. Чтобы воспользоваться шаблоном MVVM , вам необходимо распределить код в нескольких местах на уровнях вашего приложения. Вы также должны использовать конструкции эзотерического программирования , такие как шаблоны и выражения lamba .

Для обычного модального диалогового окна? Вы определенно делаете что-то не так - реализация MVVM не должна быть такой сложной.

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

MVVM, MVC, Document-View и т. Д. - это старое семейство шаблонов. Есть недостатки, но нет фатальных недостатков того типа, который вы описываете.

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

Я бы посоветовал прочитать эту статью Упрощение WPF TreeView с помощью шаблона ViewModel внимательно посмотрите, как можно хорошо реализовать MVVM и позволить вам изменить менталитет форм выигрыша на новый образ мышления в MVVM. Короче говоря, когда вы хотите что-то сделать, сначала примените логику к ViewModel, а не к View. Вы хотите выбрать товар? Изменить значок? Не перебирайте элементы пользовательского интерфейса, просто обновите свойства модели и позвольте привязке данных сделать все необходимое.