WPF中MVVM的项目结构

Posted 2023-02-22

【中文标题】WPF中MVVM的项目结构

【英文标题】：Project structure for MVVM in WPF

【发布时间】：2013-09-20 11:27:17

【问题描述】：

在 WPF 中使用 MVVM 时，您最终得到的项目结构是什么？

从我现在看到的教程来看，它们通常有文件夹：Model、ViewModel 和 看法。

在 Model 中，您可以放置​​诸如 Person 之类的类来捕获数据 和逻辑。

在 ViewModel 中，您可以实例化 Model 中定义的类。视图包含 .xaml 文件。

编辑：我编辑我的原始帖子以发送示例项目结构。 我有与此相关的问题。我如何组织这些： 应用程序配置 应用程序.xaml MainWindow.xaml

我应该像现在一样将它们留在外面还是应该将它们放在某个文件夹中？

【问题讨论】：

您的问题是关于“项目结构”还是关于什么是 MVVM ？基本上在文件夹“模型”中放置模型，在“视图模型”中放置视图模型，在“视图”中放置视图......

【参考方案1】：

您已经描述了通常或常见的文件夹布局。根据经验，我更喜欢为模型数据类型添加一个单独的文件夹（或大型应用程序中的项目），例如您提到的典型 Person 类。我这样做的原因是因为这通常会成为最大的项目之一。我还将它拆分为以下子文件夹：

DataTypes
    Collections
    Enums
    Interfaces

对于应用程序Converter 类、扩展方法类、实用程序（或服务）类，我也有单独的文件夹（或大型应用程序中的项目）。最后，我有与应用程序文件夹结构非常匹配的测试项目。总的来说，这大概是我的文件夹的样子：

Solution

    Third Party Libraries <<< (Solution Folder)

    StartUp Project
        Images
        Resources

    Converters

    DataTypes
        Collections
        Enums
        Interfaces <<< (For Data Type classes)

    Extensions

    Models
        Data Controllers
        Data Providers
        Interfaces <<< (For swapping Model classes out in test projects)

    Utilities (Or Services)
        Interfaces <<< (For swapping Utilities classes out in test projects)

    View Models
        Commands

    Views
        Attached Properties
        Controls

更新>>>

项目和文件夹一样，只是提供了分隔级别。它们还帮助我规划我的应用程序命名空间。例如，Collections 文件夹/项目中的代码类将位于 ApplicationName.DataTypes.Collections 命名空间中。 Data Providers 文件夹/项目中的类将具有 ApplicationName.Models.DataProviders 命名空间。

此外，在大型应用程序中，我的项目名称来自它们在此层次结构中的位置...例如，我的DataTypes 项目实际上称为ApplicationName.DataTypes，而我的Models 项目称为ApplicationName.Models。 Collections 和 DataProviders 部分是文件夹，以及第二级之后的所有项目，例如。 Enums、Images、Commands等

【讨论】：

你把命令放在视图模型里有意思吗？怎么会？我看到很多人只是将 Commands 与其他文件夹分开。

将Commands 放入ViewModels 只是消除了在ViewModels 项目中添加另一个引用的需要。我曾经为Commands 有一个单独的项目，但我很快意识到ViewModels 是唯一使用它们的项目，因此将它移到那里似乎是合乎逻辑的。另外，我在那个文件夹里只有一门课；它是“RelayCommand”的一种形式，所以我所有的Command 对象都只使用delegates 和普通方法。 如果我有很多实际的Command 类，我可能想给它自己的项目。

嗯，所有这些都是独立的项目？它们不是文件夹吗？

它们可以是...我在小型应用程序中使用文件夹，在大型应用程序中使用项目。这仅取决于每个真正有多少类。

@Sheridan 特别是在单个项目具有非常复杂和庞大的视图和虚拟机的情况下，您对“功能驱动结构”有何看法（正如“Benoit Blanchon”在他的回答中提到的那样） ) 而不是拥有单独的 Views 和 ViewModels 文件夹？

【参考方案2】：

大多数人使用您提到的“标准”结构：

型号/ CarModel.cs DriverModel.cs 视图模型/ CarViewModel.cs DriverViewModel.cs 查看/ CarView.xaml DriverView.xaml

我认为它受欢迎的原因是因为有些人会争辩说你应该能够将模型、视图模型和视图放在不同的程序集中。

同样使用这种结构，您可以轻松地为其他 WPF 内容添加文件夹：Converters/、Resources/ 等。

在我的团队中，我们使用这种结构，但名称是复数形式（例如 Models/ViewModels/Views）。

但是，大多数时候，模型类是在其他程序集/命名空间中定义的；在这种情况下，我们甚至没有Models/ 文件夹。

对于大型项目，我们将子文件夹添加到 Models/、ViewModels/ 和 Views/

为了完整起见，值得一提的是，您可能会发现一些人使用“功能驱动”结构：

汽车/ CarModel.cs CarViewModel.cs CarView.xaml 驱动程序/ DriverModel.cs DriverViewModel.cs DriverView.xaml

但这很罕见。

【讨论】：

您能否提供一些反馈，我编辑了我的原始帖子？具体来说，您如何处理这三个文件 App.config App.xaml MainWindow.xaml？

App.xaml 和 App.config 留在项目的根目录。 MainWindow.xaml 应该进入 Views/（并且有一个视图模型）

如果我只有一个窗口怎么办？我想我需要 Views 中的一个 xaml 文件，ViewModels 中的一个相应文件，以及 Models 中的一个文件。对吗？

特征驱动结构在复杂的应用程序中很常见，因为它们可以更好地集中注意力。但是，我只在那里看到过视图和视图模型，从来没有看到模型。无论如何，它们都在一个单独的程序集中。

我现在看到的特征驱动结构的唯一问题是，如果您将例如 DriverModel 放在那里，您可能需要根据需要该模型的位置添加大量引用。如果您将所有模型都这样排序，则每个模型可能只有一个参考，具体取决于您使用的数量。

【参考方案3】：

我通常是这样的：

主应用程序 (.exe) - 全局样式等 Common Lib WPF - WPF 的基类和助手 Common Lib General - 模型的基类和助手 基础架构 - 依赖注入、日志记录等 VM 接口 M 接口 包含视图和相应视图模型的多个库 - 也可以在此处拆分 多个包含模型的库

所有依赖项都基于仅通过 DI 解析的接口。

【参考方案4】：

朋友们，我发现的类似问题的解决方案是创建一个单独的项目，WPF 类型，我称之为 Startup，仅使用 App.xaml（和 App.xaml.cs）。

其中我指的是 View 和 ViewModel 的项目。因此视图没有依赖关系，ViewModel 只“看到”视图和业务。

在 App.xaml.cs 中声明并实例化我的 MainWindow，然后加载我的应用的一些基本属性并导航到登录页面（我正在使用一个窗口并在其中浏览多个页面）。

【讨论】：

嗨，Gaspar，您介意发布更多其他扩展文件夹的屏幕截图吗？它将帮助我们 MVVM 的初学者了解经验丰富的开发人员如何构建他们的解决方案。非常感谢。