在 WPF 中使用 MVVM 时，您最终得到的项目结构是什么？
从我现在看到的教程来看，它们通常有文件夹：Model、ViewModel 和 看法。
在 Model 中，您可以放置诸如 Person 之类的类来捕获数据 和逻辑。
在 ViewModel 中，您可以实例化 Model 中定义的类。视图包含 .xaml 文件。
编辑：我编辑我的原始帖子以发送示例项目结构。 我有与此相关的问题。我如何组织这些： 应用程序配置 应用程序.xaml MainWindow.xaml
我应该像现在一样将它们留在外面还是应该将它们放在某个文件夹中？
【问题讨论】：
您已经描述了通常或常见的文件夹布局。根据经验，我更喜欢为模型数据类型添加一个单独的文件夹（或大型应用程序中的项目），例如您提到的典型 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 放入ViewModels 只是消除了在ViewModels 项目中添加另一个引用的需要。我曾经为Commands 有一个单独的项目，但我很快意识到ViewModels 是唯一使用它们的项目，因此将它移到那里似乎是合乎逻辑的。另外，我在那个文件夹里只有一门课；它是“RelayCommand”的一种形式，所以我所有的Command 对象都只使用delegates 和普通方法。 如果我有很多实际的Command 类，我可能想给它自己的项目。
大多数人使用您提到的“标准”结构：
我认为它受欢迎的原因是因为有些人会争辩说你应该能够将模型、视图模型和视图放在不同的程序集中。
同样使用这种结构，您可以轻松地为其他 WPF 内容添加文件夹：Converters/、Resources/ 等。
在我的团队中，我们使用这种结构，但名称是复数形式（例如 Models/ViewModels/Views）。
但是，大多数时候，模型类是在其他程序集/命名空间中定义的；在这种情况下，我们甚至没有Models/ 文件夹。
对于大型项目，我们将子文件夹添加到 Models/、ViewModels/ 和 Views/
为了完整起见，值得一提的是，您可能会发现一些人使用“功能驱动”结构：
但这很罕见。
【讨论】：
App.xaml 和 App.config 留在项目的根目录。 MainWindow.xaml 应该进入 Views/（并且有一个视图模型）
我通常是这样的：
所有依赖项都基于仅通过 DI 解析的接口。
【讨论】：