打开文件对话框 MVVM

Question

好的，我真的很想知道 MVVM 专家开发人员如何处理 WPF 中的 openfile 对话框。

我真的不想在我的 ViewModel 中执行此操作（其中“浏览”是通过 DelegateCommand 引用的），

void Browse(object param)
{
    //Add code here
    OpenFileDialog d = new OpenFileDialog();

    if (d.ShowDialog() == true)
    {
        //Do stuff
    }
}

因为我认为这违背了 MVVM 方法。

我该怎么办？

Answer 1

长话短说：
解决方案是显示类中的用户交互，该类是视图组件的一部分。
这意味着，这样的类必须是视图模型未知的类，因此不能被视图模型调用。
当然，解决方案可以涉及代码隐藏实现，因为在评估解决方案是否符合MVVM时，代码隐藏并不相关。

除了回答原来的问题之外，这个答案还试图提供关于一般问题的替代视图，为什么从视图模型控制对话框等 UI 组件违反了 MVVM 设计模式，以及为什么对话框服务等解决方法不能解决问题。

1 MVVM 和对话框

1.1 对常见建议的批评

几乎所有的答案都遵循这样的误解：MVVM 是一种模式，它针对类级别依赖关系，并且需要 空的代码隐藏文件。 但这是一种架构模式，试图在应用程序/组件级别解决不同的问题：保持业务领域与 UI 分离。
大多数人（这里是 SO）都同意视图模型不应该处理对话框，但随后建议将 UI 相关逻辑移至辅助类（无论它称为辅助类还是服务），该类仍然由视图控制型号。
这（尤其是服务版本）也称为依赖关系隐藏。 此类模式被视为反模式。 服务定位器是最臭名昭著的依赖隐藏反模式。

这就是为什么我将任何涉及将 UI 逻辑从视图模型类提取到单独的类（在视图模型组件中）的模式称为反模式。 它没有解决最初的问题：如何更改应用程序结构或类设计，以便从视图模型（或模型）类中删除 UI 相关职责并将其移回视图相关类。
换句话说：关键逻辑仍然是视图模型组件的一部分。

因此，我不建议实施涉及对话服务（无论它是否隐藏在界面后面）的解决方案，例如已接受的解决方案。 如果您关心编写符合 MVVM 设计模式的代码，那么就不要在视图模型内处理对话框视图或 UI 定向消息传递。

引入一个接口来解耦类级依赖关系，例如 IFileDialogService 接口，称为依赖反转原则（SOLID 中的 D），与 MVVM 无关。 当它与MVVM无关时，它就无法解决MVVM相关问题。 当室温与建筑物是四层建筑还是摩天大楼无关时，改变室温永远无法将任何建筑物变成摩天大楼。
MVVM 不是依赖倒置 的同义词。

MVVM 是一种架构设计模式，而 依赖倒置 是一种 OO 语言原则，与构建应用程序（也称为软件架构）无关。 构造应用程序的不是接口（或抽象类型），而是抽象对象或实体（例如组件或模块），例如“模型 - 视图 - 视图模型”。 接口只能帮助“物理”地解耦模块。 它不会删除组件关联。

1.2 为什么对话框或处理Window总体感觉如此奇怪？

我们必须记住，像 Microsoft.Win32.OpenFileDialog 这样的对话框控件是“低级”本机 Windows 控件。 他们没有必要的 API 来顺利集成到 MVVM 环境中。 由于其本质，它们在集成到 WPF 等高级框架中的方式存在一些限制。 一般来说，对话框或本机窗口主机是所有高级框架的已知“弱点”。

对话框通常基于Window 或抽象CommonDialog 类。 Window 类是一个 ContentControl，因此允许样式和模板定位内容。
一个很大的限制是，Window 必须始终是根元素。 您无法将其作为子项添加到可视化树中，例如使用触发器显示/启动它或将其托管在 DataTemplate 中。
对于 CommonDialog，它无法添加到可视化树中，因为它不扩展 UIElement。

因此，基于 Window 或 CommonDialog 的类型必须始终从代码隐藏中显示，我想这就是正确处理此类控件的巨大混乱的原因。
此外，许多开发人员，尤其是刚刚接触 MVVM 的初学者，都认为代码隐藏违反了 MVVM。
由于某些不合理的原因，他们发现在视图模型组件中处理对话框视图的违规性较小。

由于其 API，Window 看起来像一个简单的控件（事实上，它扩展了 ContentControl）。 但在底层，它与操作系统的低层架构挂钩。 要实现此目的需要大量非托管代码。 来自 MFC 等低级 C++ 框架的开发人员确切地知道幕后发生了什么。

Window 和 CommonDialog 类都是真正的混合体：它们是 WPF 框架的一部分，但为了表现得像或实际上成为本机操作系统窗口，它们也必须是低级操作系统基础结构的一部分。
WPF Window 以及 CommonDialog 类基本上是复杂的低级操作系统 API 的包装器。 这就是为什么与纯框架控件相比，该控件有时会有一种奇怪的感觉（从开发人员的角度来看）。
将 Window 作为简单的 ContentControl 出售是非常具有欺骗性的。 但由于 WPF 是一个高级框架，所有低级细节在设计上都对 API 隐藏。
我们必须接受这样的事实：我们必须仅使用 C# 来处理基于 Window 和 CommonDialog 的控件。

如果您愿意放弃本机外观和感觉以及一般操作系统集成以获得主题和任务栏等本机功能，您可以通过创建自定义对话框来改进处理，例如，通过扩展 Control 或Popup，将相关属性公开为 DependencyProperty。 然后，您可以像平常一样设置数据绑定和 XAML 触发器来控制可见性。

1.3 为什么MVVM？

如果没有复杂的设计模式或应用程序结构，开发人员将直接将数据库数据加载到表控件并将 UI 逻辑与业务逻辑混合。 在这种情况下，更改为不同的数据库会破坏 UI。 但更糟糕的是，更改 UI 将需要更改处理数据库的逻辑。 当改变逻辑时，你还需要改变相关的单元测试。

真正的应用程序是业务逻辑，而不是花哨的 GUI。
您想要为业务逻辑编写单元测试 - 而不必强制包含任何 UI。
您想要修改 UI 而不修改业务逻辑和单元测试。

MVVM 是一种解决此问题并允许将 UI 与业务逻辑（即数据与视图）解耦的模式。 它比相关的设计模式 MVC 和 MVP 更有效地做到这一点。

我们不希望 UI 渗透到应用程序的较低级别。 我们希望将数据与数据呈现分开，尤其是它们的渲染（数据视图）。 例如，我们希望处理数据库访问，而不必关心使用哪些库或控件来查看数据。 这就是我们选择MVVM的原因。 因此，我们不允许在视图以外的组件中实现 UI 逻辑。

1.4 为什么将 UI 逻辑从名为 ViewModel 的类移动到单独的类仍然违反 MVVM

通过应用 MVVM，您可以有效地将应用程序构建为三个组件：模型、视图和视图模型。 理解这种划分或结构与类无关非常重要。 这是关于应用程序组件。
您可以遵循广泛传播的模式来命名或添加一个类后缀 ViewModel，但您必须知道视图模型组件通常包含许多类，其中一些类没有以 ViewModel 命名或后缀。 code> - 视图模型是一个抽象的应用程序组件。

示例：
当您从名为 MainViewModel 的大类中提取功能（例如创建数据源集合）并将此功能移至名为 ItemCreator 的新类时，则该类 ItemCreator 在逻辑上仍然是视图模型组件的一部分。
在类级别上，功能现在位于MainViewModel类之外。 在应用程序级别（架构级别），功能仍然位于同一组件中。

您可以将此示例投影到经常提出的对话框服务上：将对话框逻辑从视图模型提取到名为 DialogService 的专用类不会将逻辑移出视图模型组件：视图模型 仍然取决于这个提取的功能。
视图模型仍然参与 UI 逻辑，例如通过显式调用“服务”来控制对话框何时显示以及控制对话框类型本身（例如文件打开、文件夹选择、颜色选择器等）。 ).
这一切都需要了解 UI 的业务细节。 据了解，根据定义，该组件不属于视图模型组件。 当然，这样的知识引入了从视图模型组件到视图组件的耦合/依赖性。

职责根本不会改变，因为您命名了一个类 DialogService 而不是 DialogViewModel。

因此，DialogService 是一种反模式，它隐藏了真正的问题：实现了依赖于 UI 并执行 UI 逻辑的视图模型类。

1.5 编写后台代码是否违反了MVVM设计模式？

MVVM 是一种设计模式，设计模式与每个定义库、框架以及语言或编译器无关。 因此，在谈论MVVM时，代码隐藏并不是一个话题。

代码隐藏文件绝对是编写 UI 代码的有效上下文。 它只是另一个包含 C# 代码的文件。 代码隐藏意味着“具有 .xaml.cs 扩展名且包含部分类的文件”。 它也是事件处理程序的唯一位置。 而且您不想远离事件。

为什么存在“代码隐藏中没有代码”这一口头禅？
对于刚接触 WPF、UWP 或 Xamarin 的人来说，比如来自 WinForms 等框架的熟练且经验丰富的开发人员，我们必须强调，使用 XAML 应该是编写 UI 代码的首选方式。 使用 C# 实现 Style 或 DataTemplate（例如在代码隐藏文件中）过于复杂，并且生成的代码非常难以阅读 => 很难理解=> 难以维护。
XAML 非常适合此类任务。 视觉上冗长的标记风格完美地表达了 UI 的结构。 它在这方面做得比 C# 等要好得多。 尽管像 XAML 这样的标记语言可能会让人觉得不如某些语言或者不值得学习，但它绝对是实现 GUI 时的首选。 我们应该努力使用 XAML 编写尽可能多的 GUI 代码。

但这些考虑因素与MVVM设计模式完全无关。

代码隐藏只是一个编译器概念，由partial指令实现（在 C# 中）与 XAML 中的 x:Class 指令配对。

这就是为什么代码隐藏与任何设计模式无关。 这就是为什么 XAML 和 C# 都不能与任何设计模式有任何关系。

---

2 解决方案

就像OP正确得出的结论一样：

“我真的不想在我的系统中执行此操作[打开文件选择器对话框]
ViewModel（其中“浏览”是通过 DelegateCommand 引用的）。
因为我认为这违背了 MVVM 方法论。

2.1 一些基本考虑因素

• 对话框是一个 UI 控件：一个视图。
• 对话框控件或一般控件（例如显示/隐藏）的处理是 UI 逻辑。
• MVVM 要求：视图模型不知道 UI 或用户的存在。 因此，需要视图模型主动等待或调用用户输入的控制流确实需要进行一些重新设计：这是一个严重的违规行为，并且破坏了架构边界由MVVM决定。
• 显示对话框需要了解何时显示它以及何时关闭它。
• 显示对话框需要了解 UI 和用户，因为显示对话框的唯一原因是与用户交互。
• 显示对话框需要了解当前 UI 上下文（以便选择适当的对话框类型）。
• 破坏 MVVM 模式的并不是对 OpenFileDialog 或 UIElement 等程序集或类的依赖，而是 UI 逻辑的实现或引用。查看模型组件或模型组件（尽管这样的依赖关系可能是一个有价值的提示）。
• 出于同样的原因，从模型组件显示对话框也是错误的。
• 唯一负责 UI 逻辑的组件是视图组件。
• 从 MVVM 的角度来看，没有什么比 C#、XAML、C++ 或 VB.NET 更好的了。 这意味着，没有像 partial 或相关的臭名昭著的代码隐藏文件 (*.xaml.cs) 这样的东西。 代码隐藏的概念的存在是为了允许编译器将类的 XAML 部分与其 C# 部分合并。 合并后，两个文件都被视为一个类：这是一个纯粹的编译器概念。 partial 是一种神奇的方法，可以使用 XAML 编写类代码（真正的编译器语言仍然是 C# 或任何其他 IL 兼容语言）。
• ICommand 是 .NET 库的一个接口，因此不是讨论 MVVM 时的主题。 相信每个操作都必须由视图模型中的ICommand实现来触发是错误的。
  只要保持组件之间的单向依赖关系，事件仍然是一个非常有用的概念，符合MVVM。 总是强制使用 ICommand 而不是使用事件会导致不自然且有异味的代码，如 OP 提供的代码。
• 不存在这样的“规则”：ICommand 必须仅由视图模型类实现。 它也可以通过视图类来实现。
  事实上，视图通常实现RoatedCommand（或RoulatedUICommand），它们都是ICommand的实现，也可以用来触发显示来自例如 Window 或任何其他控件的对话框。
  我们有数据绑定来允许 UI 与视图模型交换数据（从数据源的角度来看是匿名的）。 但由于数据绑定无法调用操作（至少在 WPF 中 - 例如，UWP 允许这样做），因此我们有 ICommand 和 ICommandSource 来实现这一点。
• 一般来说，接口不是 MVVM 的相关概念。 因此，引入接口（例如，IFileDialogService）永远无法解决MVVM相关问题。
• 服务或辅助类不是 MVVM 的概念。 因此，引入服务或辅助类永远无法解决 MVVM 相关问题。
• 一般来说，类及其名称或类型名称与MVVM无关。 将视图模型代码移至单独的类，即使该类未命名或以 ViewModel 为后缀，也无法解决 MVVM 相关问题。

2.2 结论

解决方案是显示类中的用户交互，该类是视图组件的一部分。
这意味着，这样的类必须是视图模型未知的类，因此视图模型无法调用该类。

此逻辑可以直接在代码隐藏文件或任何其他类中实现视图的（文件）。 实现可以是一个简单的帮助器类或更复杂的（附加的）行为。

要点是：对话框（即 UI 组件）必须由视图组件单独处理，因为这是唯一包含 UI 相关逻辑的组件。 由于视图模型不了解视图，因此它无法主动与视图进行通信。 仅允许被动通信（数据绑定、事件）。

我们始终可以使用视图模型引发的事件来实现特定的流程，视图可以观察到这些事件，以便采取诸如使用对话框与用户交互之类的操作。

存在使用视图模型优先方法的解决方案，该方法从一开始就不违反MVVM。 但仍然：设计不当的职责也可能使该解决方案变成反模式。

3 如何解决某些对话框请求的需要

大多数时候，我们可以通过修复应用程序的设计来消除在应用程序内显示对话框的需要。

由于对话框是一个支持与用户交互的 UI 概念，因此我们必须使用 UI 设计规则来评估对话框。
也许 UI 设计中最著名的设计规则是 Nielsen 和 Molich 在 90 年代提出的 10 条规则。

一条重要的规则是关于错误预防的：它指出

a) 我们必须防止任何类型的错误，尤其是与输入相关的错误，因为
b) 用户不喜欢他的工作效率被错误消息和对话框打断。

a) 表示：输入数据验证。 不允许无效数据进入业务逻辑。
b) 意味着：尽可能避免向用户显示对话框。 切勿从应用程序内显示对话框，并让用户显式触发对话框，例如单击鼠标（无意外中断）。

遵循这个简单的规则当然总是消除显示由视图模型触发的对话框的需要。

从用户的角度来看，应用程序是一个黑盒子：它输出数据、接受数据并处理输入数据。 如果我们控制数据输入以防止无效数据，我们就可以消除未定义或非法状态并确保数据完整性。 这意味着无需从应用程序内部向用户显示对话框。 仅那些由用户明确触发的。

例如，一个常见的场景是我们的模型需要将数据保存在文件中。 如果目标文件已经存在，我们要要求用户确认覆盖该文件。

遵循错误预防的规则，我们总是首先让用户选择文件：无论是源文件还是目标文件，总是由用户指定通过文件对话框显式选择该文件。 这意味着，用户还必须显式触发文件操作，例如通过单击“另存为”按钮。

这样，我们可以使用文件选择器或文件保存对话框来确保仅选择现有文件。 作为奖励，我们还消除了警告用户覆盖现有文件的需要。

采用这种方法，我们满足了a)“[...]防止任何类型的错误，特别是与输入相关的错误”和b)“[...]用户不喜欢被错误消息和对话框打断”。

更新

由于人们质疑您不需要视图模型来处理对话框视图，因此通过提出额外的“复杂”要求（例如数据验证）来证明他们的观点，我被迫提供更复杂的示例来解决这些更复杂的场景（OP 最初没有要求）。

4 示例

请参阅 GitHub：MVVM-Open-FileDialog-Example 了解完整示例实现包括一个（示例#4），它使用事件聚合器来使视图模型或模型能够以完全基于事件的方式将消息发布到 UI（例如，打开一个对话框 - 尽管任何此类消息传递方向都违反了 MVVM）。 实现本身符合 MVVM 标准，但从视图模型或模型向用户显示消息的意图是实际的 MVVM 违规。 GitHub 源代码中的示例 #4 包含更详细的解释。

4.1 概述

该场景是一个简单的输入表单，用于收集用户输入（例如相册名称），然后使用 OpenFileDialog 选择保存相册名称的目标文件。
三个简单解决方案（加上 GitHub 示例中的一个额外解决方案）：

解决方案 1：非常简单且基本的代码隐藏场景。
解决方案 2：在视图模型中使用数据验证。 为了使示例简单，省略了INotifyDataErrorInfo的实现。
解决方案3：使用命令将对话框结果发送到视图模型。

解决方案 1

以下示例允许视图模型保持不知道任何 UI 组件或逻辑。

您甚至可以考虑将 FileStream 而不是文件路径传递给视图模型。 这样，您可以在创建流时直接在 UI 中处理任何错误，例如，根据需要显示一个对话框。

视图

MainWindow.xaml

<Window>
  <Window.DataContext>
    <MainViewModel />
  </Window.DataContext>

  <StackPanel>
    <!-- The data to persist -->
    <TextBox Text="{Binding AlbumName}" />

    <!-- Show the file dialog. 
         Let user explicitly trigger the file save operation. 
         This button will be disabled until the required input is valid -->
    <Button Content="Save as" 
            Click="SaveAlbumNameToFile_OnClick" />
  </StackPanel>
</Window>

MainWindow.xaml.cs

partial class MainWindow : Window
{
  public MainWindow()
    => InitializeComponent();

  private void SaveAlbumNameToFile_OnClick(object sender, EventArgs e)
  {
    var dialog = new OpenFileDialog();

    if (dialog.ShowDialog() == true)
    {
      // Consider to create the FileStream here to handle errors 
      // related to the user's picked file in the view. 
      // If opening the FileStream succeeds, we can pass it over to the viewmodel.
      // Also consider wrapping the actual call to the view model into a try-catch block 
      // in order to provide feedback to the user if needed.
      string destinationFilePath = dialog.FileName;
      (this.DataContext as MainViewModel)?.SaveAlbumName(destinationFilePath);
    }
  }
}

视图模型

MainViewModel.cs

class MainViewModel : INotifyPropertyChanged
{
  // Raises PropertyChanged
  public string AlbumName { get; set; }
    
  // A model class that is responsible to persist and load data
  private DataRepository DataRepository { get; }
    
  public MainViewModel() => this.DataRepository = new DataRepository();
    
  // Since 'destinationFilePath' was picked using a file dialog, 
  // this method can't fail.
  public void SaveAlbumName(string destinationFilePath)
    => this.DataRepository.SaveData(this.AlbumName, destinationFilePath);
}

---

解决方案2

更现实的解决方案是添加专用的TextBox 作为输入字段，以通过复制和粘贴来收集目标文件路径。
此 TextBox 绑定到视图模型类，理想情况下该类实现 INotifyDataErrorInfo 来验证输入。

附加按钮将打开可选的文件选择器视图，以允许用户选择浏览文件系统以选择目标。

最后，持久化操作由“另存为”按钮触发：

View

MainWindow.xaml

<Window>
  <Window.DataContext>
    <MainViewModel />
  </Window.DataContext>    

  <StackPanel>

    <!-- The data to persist -->
    <TextBox Text="{Binding AlbumName}" />

    <!-- Alternative file path input, validated using INotifyDataErrorInfo validation 
         e.g. using File.Exists to validate the file path -->
    <TextBox x:Name="FilePathTextBox" 
             Text="{Binding DestinationPath, ValidatesOnNotifyDataErrors=True}" />

    <!-- Option to search a file using the file picker dialog -->
    <Button Content="Browse" Click="PickFile_OnClick" />

    <!-- Let user explicitly trigger the file save operation. 
         This button will be disabled until the required input is valid -->
    <Button Content="Save as" 
            Command="{Binding SaveAlbumNameCommand}" />
  </StackPanel>
</Window>

MainWindow.xaml.cs

partial class MainWindow : Window
{
  public MainWindow()
  {
    InitializeComponent();
  }

  private void PickFile_OnClick(object sender, EventArgs e)
  {
    var dialog = new OpenFileDialog();
    if (dialog.ShowDialog() == true)
    {
      this.FilePathTextBox.Text = dialog.FileName;

      // Since setting the property explicitly bypasses the data binding, 
      // we must explicitly update it by calling BindingExpression.UpdateSource()
      this.FilePathTextBox
        .GetBindingExpression(TextBox.TextProperty)
        .UpdateSource();
    }
  }
}

View Model

MainViewModel.cs

class MainViewModel : INotifyPropertyChanged, INotifyDataErrorInfo
{
  private string albumName;
  public string AlbumName
  {
    get => this.albumName;
    set
    {
      this.albumName = value;
      OnPropertyChanged();
    }
  }

  private string destinationPath;
  public string DestinationPath
  {
    get => this.destinationPath;
    set
    {
      this.destinationPath = value;
      OnPropertyChanged();

      ValidateDestinationFilePath();
    }
  }

  public ICommand SaveAlbumNameCommand => new RelayCommand(
    commandParameter => ExecuteSaveAlbumName(this.TextValue),
    commandParameter => true);

  // A model class that is responsible to persist and load data
  private DataRepository DataRepository { get; }

  // Default constructor
  public MainViewModel() => this.DataRepository = new DataRepository();

  private void ExecuteSaveAlbumName(string destinationFilePath)
  {
    // Use a aggregated/composed model class to persist the data
    this.DataRepository.SaveData(this.AlbumName, destinationFilePath);
  }
}

---

解决方案 3

以下解决方案是第二种方案的更优雅的版本。 它使用 ICommandSource.CommandParameter 属性将对话框结果发送到视图模型（而不是上一个示例中使用的数据绑定）。
使用绑定验证来验证可选用户输入（例如复制和粘贴）的验证：

View

MainWindow.xaml

<Window x:Name="Window">
  <Window.DataContext>
    <MainViewModel />
  </Window.DataContext> 

  <StackPanel> 

    <!-- The data to persist -->
    <TextBox Text="{Binding AlbumName}" />

    <!-- Alternative file path input, validated using binding validation 
         e.g. using File.Exists to validate the file path -->
    <TextBox x:Name="FilePathTextBox">
      <TextBox.Text>
        <Binding ElementName="Window" Path="DestinationPath">
          <Binding.ValidationRules>
            <FilePathValidationRule />
          </Binding.ValidationRules>
        </Binding>
      </TextBox.Text>
    </TextBox>

    <!-- Option to search a file using the file picker dialog -->
    <Button Content="Browse" Click="PickFile_OnClick" />

    <!-- Let user explicitly trigger the file save operation. 
         This button will be disabled until the required input is valid -->
    <Button Content="Save as" 
            CommandParameter="{Binding ElementName=Window, Path=DestinationPath}" 
            Command="{Binding SaveAlbumNameCommand}" />
  </StackPanel>
</Window>

FilePathValidationRule.cs

class FilePathValidationRule : ValidationRule
{
  public override ValidationResult Validate(object value, CultureInfo cultureInfo)
    => value is string filePath && File.Exists(filePath)
      ? ValidationResult.ValidResult
      : new ValidationResult(false, "File path does not exist.");
}

MainWindow.xaml.cs

partial class MainWindow : Window
{
  public static readonly DependencyProperty DestinationPathProperty = DependencyProperty.Register(
    "DestinationPath",
    typeof(string),
    typeof(MainWindow),
    new PropertyMetadata(default(string)));

  public string DestinationPath
  {
    get => (string)GetValue(MainWindow.DestinationPathProperty);
    set => SetValue(MainWindow.DestinationPathProperty, value);
  }

  public MainWindow()
  {
    InitializeComponent();
  }

  private void PickFile_OnClick(object sender, EventArgs e)
  {
    var dialog = new OpenFileDialog();
    if (dialog.ShowDialog() == true)
    {
      this.DestinationPath = dialog.FileName;
    }
  }
}

模型

MainViewModel.cs

class MainViewModel : INotifyPropertyChanged, INotifyDataErrorInfo
{
  private string albumName;
  public string AlbumName
  {
    get => this.albumName;
    set
    {
      this.albumName = value;
      OnPropertyChanged();
    }
  }

  public ICommand SaveAlbumNameCommand => new RelayCommand(
    commandParameter => ExecuteSaveAlbumName(commandParameter as string),
    commandParameter => true);

  // A model class that is responsible to persist and load data
  private DataRepository DataRepository { get; }

  // Default constructor
  public MainViewModel() => this.DataRepository = new DataRepository();

  private void ExecuteSaveAlbumName(string destinationFilePath)
  {
    // Use a aggregated/composed model class to persist the data
    this.DataRepository.SaveData(this.AlbumName, destinationFilePath);
  }
}

Answer 2

在这里最好的办法就是使用服务。

服务只是一个类，您可以从服务的中央存储库（通常是 IOC 容器）访问该类。 然后该服务会实现您需要的功能，例如 OpenFileDialog。

因此，假设您在 Unity 容器中有一个 IFileDialogService，您可以这样做...

void Browse(object param)
{
    var fileDialogService = container.Resolve<IFileDialogService>();

    string path = fileDialogService.OpenFileDialog();

    if (!string.IsNullOrEmpty(path))
    {
        //Do stuff
    }
}

Answer 3

我本来想对其中一个答案发表评论，但可惜的是，我的声誉不够高，无法这样做。

诸如 OpenFileDialog() 之类的调用违反了 MVVM 模式，因为它暗示了视图模型中的视图（对话框）。 视图模型可以调用类似 GetFileName() 的方法（也就是说，如果简单绑定还不够），但它不应该关心如何获取文件名。

Answer 4

我使用一个服务，例如，我可以将其传递到我的 viewModel 的构造函数中或通过依赖项注入进行解析。
例如

public interface IOpenFileService
{
    string FileName { get; }
    bool OpenFileDialog()
}

和一个实现它的类，在底层使用 OpenFileDialog。 在 viewModel 中，我只使用接口，因此可以根据需要模拟/替换它。

Answer 5

ViewModel 不应该打开对话框，甚至不应该知道它们的存在。 如果 VM 位于单独的 DLL 中，则项目不应引用PresentationFramework。

我喜欢在常见对话框的视图中使用辅助类。

帮助器类公开窗口在 XAML 中绑定到的命令（而不是事件）。 这意味着在视图中使用 RelayCommand。 辅助类是一个 DepencyObject，因此它可以绑定到视图模型。

class DialogHelper : DependencyObject
{
    public ViewModel ViewModel
    {
        get { return (ViewModel)GetValue(ViewModelProperty); }
        set { SetValue(ViewModelProperty, value); }
    }

    public static readonly DependencyProperty ViewModelProperty =
        DependencyProperty.Register("ViewModel", typeof(ViewModel), typeof(DialogHelper),
        new UIPropertyMetadata(new PropertyChangedCallback(ViewModelProperty_Changed)));

    private static void ViewModelProperty_Changed(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        if (ViewModelProperty != null)
        {
            Binding myBinding = new Binding("FileName");
            myBinding.Source = e.NewValue;
            myBinding.Mode = BindingMode.OneWayToSource;
            BindingOperations.SetBinding(d, FileNameProperty, myBinding);
        }
    }

    private string FileName
    {
        get { return (string)GetValue(FileNameProperty); }
        set { SetValue(FileNameProperty, value); }
    }

    private static readonly DependencyProperty FileNameProperty =
        DependencyProperty.Register("FileName", typeof(string), typeof(DialogHelper),
        new UIPropertyMetadata(new PropertyChangedCallback(FileNameProperty_Changed)));

    private static void FileNameProperty_Changed(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        Debug.WriteLine("DialogHelper.FileName = {0}", e.NewValue);
    }

    public ICommand OpenFile { get; private set; }

    public DialogHelper()
    {
        OpenFile = new RelayCommand(OpenFileAction);
    }

    private void OpenFileAction(object obj)
    {
        OpenFileDialog dlg = new OpenFileDialog();

        if (dlg.ShowDialog() == true)
        {
            FileName = dlg.FileName;
        }
    }
}

辅助类需要对 ViewModel 实例的引用。 请参阅资源字典。 构造完成后，将设置 ViewModel 属性（在 XAML 的同一行中）。 这是当帮助器类上的 FileName 属性绑定到视图模型上的 FileName 属性时。

<Window x:Class="DialogExperiment.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:DialogExperiment"
        xmlns:vm="clr-namespace:DialogExperimentVM;assembly=DialogExperimentVM"
        Title="MainWindow" Height="350" Width="525">
    <Window.Resources>
        <vm:ViewModel x:Key="viewModel" />
        <local:DialogHelper x:Key="helper" ViewModel="{StaticResource viewModel}"/>
    </Window.Resources>
    <DockPanel DataContext="{StaticResource viewModel}">
        <Menu DockPanel.Dock="Top">
            <MenuItem Header="File">
                <MenuItem Header="Open" Command="{Binding Source={StaticResource helper}, Path=OpenFile}" />
            </MenuItem>
        </Menu>
    </DockPanel>
</Window>

Answer 6

我已经用这种方式解决了这个问题：

• 在 ViewModel 中，我定义了一个接口并在
  ViewModel
• 在 View 中我已经实现了这个接口。

下面的代码中未实现 CommandImpl。

视图模型：

namespace ViewModels.Interfaces
{
    using System.Collections.Generic;
    public interface IDialogWindow
    {
        List<string> ExecuteFileDialog(object owner, string extFilter);
    }
}

namespace ViewModels
{
    using ViewModels.Interfaces;
    public class MyViewModel
    {
        public ICommand DoSomeThingCmd { get; } = new CommandImpl((dialogType) =>
        {
            var dlgObj = Activator.CreateInstance(dialogType) as IDialogWindow;
            var fileNames = dlgObj?.ExecuteFileDialog(null, "*.txt");
            //Do something with fileNames..
        });
    }
}

视图：

namespace Views
{
    using ViewModels.Interfaces;
    using Microsoft.Win32;
    using System.Collections.Generic;
    using System.Linq;
    using System.Windows;

    public class OpenFilesDialog : IDialogWindow
    {
        public List<string> ExecuteFileDialog(object owner, string extFilter)
        {
            var fd = new OpenFileDialog();
            fd.Multiselect = true;
            if (!string.IsNullOrWhiteSpace(extFilter))
            {
                fd.Filter = extFilter;
            }
            fd.ShowDialog(owner as Window);

            return fd.FileNames.ToList();
        }
    }
}

XAML：

<Window xmlns:views="clr-namespace:Views"
        xmlns:viewModels="clr-namespace:ViewModels">    
    <Window.DataContext>
        <viewModels:MyViewModel/>
    </Window.DataContext>
    <Grid>
        <Button Content = "Open files.." Command="{Binding DoSomeThingCmd}"
                CommandParameter="{x:Type views:OpenFilesDialog}"/>
    </Grid>
</Window>

Answer 7

拥有服务就像从视图模型中打开一个视图。
我看到了一个依赖属性，在更改该属性时，我打开 FileDialog 并读取路径，更新该属性，从而更新虚拟机的绑定属性

Answer 8

该问题询问“专家”如何在利用 MVVM 设计模式的同时处理 WPF 中打开的文件对话框。 我不知道我是否是“专家”，但我是专业人士，所以我希望这很重要。 :)

由于这个问题特定于打开文件，我只会演示这一点，但我有另一个答案，将此解决方案扩展到任何可模板化的对话框内容。 此解决方案不涉及特定于应用程序的代码隐藏（即，用于特定于应用程序的视图的空.xaml.cs 文件）。 它还不涉及视​​图模型对视图类型（注入或其他）的依赖。

我将从应用程序端的最终结果开始。

视图：

<StackPanel local:DialogManager.ShowDialog="{Binding DialogManager.CurrentDialog}">
    <StackPanel.DataContext>
        <local:MainViewModel />
    </StackPanel.DataContext>
    <Button Command="{Binding PickFileCommand}">Open File</Button>
    <TextBlock Text="Chosen file:" />
    <TextBox IsReadOnly="True"
             Text="{Binding ChosenFilePath}" />
</StackPanel>

视图模型：

public class MainViewModel : ViewModelBase
{
    public DialogManagerViewModel DialogManager { get; } =
        new DialogManagerViewModel();

    #region ICommand PickFile Command
    private Command _PickFileCommand;
    public ICommand PickFileCommand
    {
        get
        {
            return _PickFileCommand ?? (_PickFileCommand = new Command(
                async () =>
                {
                    var fileDialog = new FileOpenDialogViewModel();
                    var result = await DialogManager.ShowDialogAsync(fileDialog);
                    if (result == null)
                    {
                        this.ChosenFilePath = "Cancelled";
                        return;
                    }
                    this.ChosenFilePath = result;
                }));
        }
    }
    #endregion

    #region string ChosenFilePath property
    private string _ChosenFilePath;
    public string ChosenFilePath
    {
        get
        {
            return _ChosenFilePath;
        }
        set
        {
            if (_ChosenFilePath == value)
                return;
            _ChosenFilePath = value;
            OnPropertyChanged();
        }
    }
    #endregion
}

这是整个应用程序特定的代码。 我会在这里暂停说，如果您认为这不是有效的 MVVM 方法，那么您最好停止阅读。 尽管我认为我的说法是有充分依据的，但我不想就这一点进行辩论。 客观地说，它将抽象的、平台无关的逻辑与 GUI 细节分开，并且它允许在 XAML 中 100% 声明性定义视图（即无代码隐藏）。 而且它具有高度可扩展性。 就我个人而言，我认为这些都是值得努力的事情，并且我已经就这个主题撰写了大量文章。 不过，如果这些事情与您无关，那么请务必遵循上面得票最高的答案中的方法。 我不会被冒犯（尽管你的开发预算可能会被冒犯）。

但如果您确实希望能够以这种方式打开文件对话框和其他对话框，请继续阅读。

我们确实需要做一些脚手架来完成这项工作，但好处是所有这些都可以在其他应用程序中重用（大多数甚至在其他平台上也是如此）。 从与平台无关的部分开始：

public enum DialogType
{
    StandardFileOpen,
    StandardFileSave,
    // others, including potentially Custom
}

public abstract class DialogViewModel : ViewModelBase
{
    private TaskCompletionSource<object> _dialogResult = new TaskCompletionSource<object>();

    public abstract DialogType DialogType { get; }
   
    public void SetResult(object result)
    {
        _dialogResult.SetResult(result);
    }

    internal Task<object> DialogResult => _dialogResult.Task;
}

public abstract class DialogViewModel<T> : DialogViewModel
{
}

public class FileOpenDialogViewModel : DialogViewModel<string>
{
    public sealed override DialogType DialogType => 
        DialogType.StandardFileOpen;
}

// A singleton instance of this class should exist
// somewhere in the view model layer, accessible to all.
public class DialogManagerViewModel : ViewModelBase
{
    #region DialogViewModel CurrentDialog property
    private DialogViewModel _currentDialog;
    // This will be bound to the GUI-specific DialogManager 
    // through a bindable property.
    public DialogViewModel CurrentDialog
    {
        get
        {
            return _currentDialog;
        }
        private set
        {
            if (_currentDialog == value)
                return;
            _currentDialog = value;
            OnPropertyChanged();
        }
    }
    #endregion

    // Returns the result of the dialog depending on the type.
    // For preset types like FileOpenDialogViewModel, the return
    // value will be the file path string, or null if cancelled.
    public async Task<T> ShowDialogAsync<T>(DialogViewModel<T> dialog)
    {
        if (this.CurrentDialog != null)
            // Support for multiple open dialogs could be achieved 
            // by using an ObservableCollection of DialogViewModels
            // instead of a single property, but I'll leave it to
            // the reader to envision such a solution.
            throw new InvalidOperationException(
                $"Only one dialog may be open at a time.");
        this.CurrentDialog = dialog;            
        var result = await dialog.DialogResult;
        this.CurrentDialog = null;
        return (result is T tresult) ? tresult : default;
    }
}

最后是 WPF 特定的部分：

public static class DialogManager
{
    #region DialogViewModel ShowDialog dependency property
    public static readonly DependencyProperty ShowDialogProperty =
        DependencyProperty.RegisterAttached(
            "ShowDialog",
            typeof(DialogViewModel),
            typeof(DialogManager),
            new PropertyMetadata(OnShowDialogChanged));
    public static DialogViewModel GetShowDialog(DependencyObject obj)
    {
        return (DialogViewModel)obj.GetValue(ShowDialogProperty);
    }
    public static void SetShowDialog(DependencyObject obj, DialogViewModel value)
    {
        obj.SetValue(ShowDialogProperty, value);
    }
    private static async void OnShowDialogChanged(
        DependencyObject sender,
        DependencyPropertyChangedEventArgs args)
    {
        if (!(args.NewValue is DialogViewModel dialog) ||
            !(sender is FrameworkElement fe))
            return;

        // Ensures that the open is executed asynchronously so that,
        // if for some reason the initiator didn't want to await the result,
        // control would return to them before the modal is actually opened.
        await Task.Yield();

        switch (dialog.DialogType)
        {
            default:
                throw new NotSupportedException("Unsupported Dialog Type");
            case DialogType.StandardFileOpen:
                OpenFileDialog openDlg = new OpenFileDialog();
                var result = openDlg.ShowDialog();
                dialog.SetResult(result == true 
                    ? openDlg.FileName 
                    : null);
                break;
            // Handle other cases, including a custom-templated
            // dialog, as shown in my other answer
            // https://stackoverflow.com/questions/454868/handling-dialogs-in-wpf-with-mvvm/78804678#78804678
        }
    }
    #endregion
}

如果我们想要做的只是显示一个文件打开对话框，那么我们就完成了。 当然，您可以轻松地将其扩展到文件保存、文件夹选择，甚至消息框。 您可以进一步扩展 FileOpenDialogViewModel 来接受过滤器参数或初始建议等。

您可能会问，“这真的比代码隐藏更好吗”？ （如果你了解我，你就会知道我是反对代码隐藏的人）。 答案是肯定的，因为并非所有代码隐藏都是一样的。

虽然 DialogManager 类与 DialogViewModel 类混合在一起，但连接不是在应用程序级别发生的 - 它发生在我称之为服务的地方 > 或图书馆级别。 无论我们如何称呼它，重点是它是可重复使用的且适应性强。 如果我们想将其移植到 WinUI、MAUI，甚至 Web（通过 Blazor），我们所要做的就是重写一个新的特定于平台的 DialogManager 就可以了。 我们想要避免的并不是所有 C# GUI 代码 - 当然这是荒谬的。 我们希望避免定制的、特定于应用程序的代码隐藏，这种代码隐藏不必要地将应用程序逻辑与 GUI 细节混合在一起，并且不提供可重用性潜力。

想象一下，如果我们采纳其他人的建议，只使用常规的代码隐藏，那么最终会出现 25 个使用文件打开对话框的地方。 然后想象一下，在某个时候我们意识到我们不想使用 OpenFileDialog，或者必须一起迁移到另一个平台。 你的假期就这样过去了。

因此，当您问“专家”（或至少是专业人士）会做什么时？ - 他们会做这样的事情。 能够扩展、最小化成本并最大化价值的东西。