Introduction

Dialogs are common in WPF applications, but in an MVVM design the important question is not whether dialogs are "good" or "bad." The real issue is whether dialog behavior is implemented in a way that preserves separation of concerns, keeps view models testable, and avoids hard-coding UI dependencies into business logic.

Core Sections

The Core MVVM Rule

In MVVM, a view model should express intent, not directly create windows. If a view model calls new Window() or MessageBox.Show(...) everywhere, it becomes tightly coupled to WPF UI details and harder to unit test.

A cleaner approach is to depend on an abstraction such as IDialogService. The view model asks for a dialog operation, and a WPF-specific service handles the actual window creation.

1public interface IDialogService
2{
3    bool Confirm(string title, string message);
4}
5
6public class EditorViewModel
7{
8    private readonly IDialogService _dialogService;
9
10    public EditorViewModel(IDialogService dialogService)
11    {
12        _dialogService = dialogService;
13    }
14
15    public void DeleteItem()
16    {
17        bool confirmed = _dialogService.Confirm(
18            "Delete item",
19            "Are you sure you want to delete this item?"
20        );
21
22        if (!confirmed)
23        {
24            return;
25        }
26
27        // Perform deletion logic here.
28    }
29}

That keeps the view model focused on decisions and application flow instead of visual behavior.

A Simple WPF Dialog Service

The WPF layer can implement the interface using MessageBox or a custom window.

1using System.Windows;
2
3public class DialogService : IDialogService
4{
5    public bool Confirm(string title, string message)
6    {
7        MessageBoxResult result = MessageBox.Show(
8            message,
9            title,
10            MessageBoxButton.YesNo,
11            MessageBoxImage.Question
12        );
13
14        return result == MessageBoxResult.Yes;
15    }
16}

This is a practical compromise. The application still uses native dialogs, but the view model is no longer responsible for rendering them.

Custom Dialog Windows With View Models

For richer dialogs such as edit forms, file metadata screens, or multistep confirmations, use a dedicated dialog view and dialog view model. The dialog service can map a dialog view model to a WPF window and return a result.

1public interface IModalDialogService
2{
3    bool? ShowDialog(object viewModel);
4}
5
6public class RenameFileViewModel
7{
8    public string Name { get; set; } = "";
9    public bool? DialogResult { get; set; }
10}

The service might create a RenameFileWindow, assign its DataContext, show it modally, and then return the result. The parent view model only knows that a dialog was requested and whether the user accepted or canceled.

That pattern scales better than pushing every popup through MessageBox, especially when dialogs contain validation, commands, or multiple fields.

Commands and Dialog State

Dialogs fit naturally with commands in MVVM. A command can ask the dialog service to open a window, and if the result is positive, continue the workflow.

1public ICommand RenameCommand => new RelayCommand(OpenRenameDialog);
2
3private void OpenRenameDialog()
4{
5    var dialogVm = new RenameFileViewModel
6    {
7        Name = SelectedFileName
8    };
9
10    bool? accepted = _modalDialogService.ShowDialog(dialogVm);
11    if (accepted == true)
12    {
13        SelectedFileName = dialogVm.Name;
14    }
15}

The view model owns the data and the decision flow. The service owns the WPF window mechanics.

When Direct Dialog Calls Are Acceptable

For tiny apps, code-behind or a direct MessageBox.Show in a view model may seem harmless. Sometimes that is an acceptable shortcut if the dialog is trivial and the app is unlikely to grow.

Still, once the application has several screens, test coverage, or reusable workflows, direct calls become a maintenance cost. They make mocking harder and scatter UI policy through business logic. If you already know the project matters, it is usually worth introducing a service early.

Common Pitfalls

• Letting a view model create concrete windows or call MessageBox.Show everywhere directly.
• Returning UI objects from the dialog service instead of simple results or data.
• Building an oversized dialog framework when a small service interface would solve the real problem.
• Treating dialogs themselves as anti-MVVM instead of focusing on whether the UI dependency is isolated properly.
• Forgetting to keep validation, commands, and result handling in the dialog view model instead of pushing everything into code-behind.

Summary

• Dialogs are fine in WPF with MVVM if the view model does not directly manage window details.
• Use a dialog service interface so view models express intent instead of creating UI objects.
• Simple confirmations can wrap MessageBox; richer flows deserve dedicated dialog views and view models.
• Commands are a natural place to trigger dialogs and react to user decisions.
• The bad practice is not "using dialogs"; it is coupling dialog implementation tightly to the view model.