WPF - MVVM 架构（Visual Studio 解决方案和项目）[关闭]

Question

我正在开发一个 MVVM 模式的 Window-App WPF 项目。目前，该应用程序有点简单（无法真正解释产品的性质），但最终它有望成长为更复杂的应用程序。

• wpf winapp 有一个本地数据库，还连接到一个 REST 服务。
• 开发时间并不是真正的首要问题；但可维护性和可测试性。
• 将使用 IOC 容器和 DI
• 计划做 1 个 ViewModel 就是做 1 个 View
• 我不想使用任何 WPF/MVVM 框架，因为这是我第一次使用 WPF-MVVM 应用程序（就像第一次在裸 DOM javascript 中编码，即使有 jquery）。

我决定使用多个项目，目前我的想法如下：

1. Product.Windows.Common（实用程序、日志记录、帮助程序等）
2. Product.Windows.Entities（数据库和 REST 实体）
3. Product.Windows.Contracts（所有接口都将驻留在此命名空间/项目中）
4. Product.Windows.Data（用于本地数据库）
5. Product.Windows.ServiceClients（用于 REST 客户端）
6. Product.Windows.App（主 WPF 项目，包含 Views/XAML）
7. Product.Windows.Models（INPChanged）
8. Product.Windows.ViewModels（INPChanged 和 ICommands）
9. Product.Windows.Tests（单元测试）

我只想问：

1. 这个架构是不是有点矫枉过正了？

2. 我是否需要为业务逻辑创建一个 Product.Windows.Business？还是应该将业务逻辑放在 ViewModel 中？

提前谢谢你:)

Answer 1

我目前正在开发具有类似结构的应用程序。项目结构看起来不错。在我的项目中，我做的事情有点不同。

Data 和 ServiceClients 程序集可能代表您的 DAL。很好，这些在不同的组件中是分开的。在数据程序集中，您将拥有存储库，在 ServiceClients 中，您将拥有服务代理。实体和合同程序集可能代表您的 BL。在这里，我认为您可以使用单个程序集。这个程序集应该被两个 DAL 程序集引用。

单独实现日志记录很好，如果您有安全性，这也应该在 Common 中实现。根据我最近读到的一本好书，.NET 中的依赖注入，实用程序和帮助程序是设计不佳/不完整的结果。这些类通常包含静态方法。但我认为这与讨论无关。

在我的项目中，我通常在与视图相同的程序集中实现 VM。这包括 RelayCommand（ICommand 实现）和实现 INPC 的 ViewModelBase。

我最近观看了 Robert Martin 的演讲。据我所知，他说过应用程序的架构应该尖叫应用程序的功能。类不应分组在称为（MVC 或 MVVM）的项目或文件夹中。这并没有告诉我们该应用程序的功能。类应该按照它们所做的事情、它们实现的特性来分组。我还没到这个阶段。我仍在对像你这样的东西进行分组:)。

我看到您只有一个测试项目。如果您在此项目中为您计划测试的所有程序集添加目录，这也可能很好。如果您不这样做，则很难找到特定程序集的测试。您可能希望为计划测试的每个程序集添加测试项目。

Answer 2

您可以根据需要组织组件，但我更喜欢以下结构： - 为项目中的每个屏幕创建 2 个类库 (dll)（其中一个具有此屏幕的视图 + 视图模型，另一个 dll 具有它的业务逻辑），因此您可以将视图和视图模型与另一个业务逻辑一起使用，并且您也可以在每个屏幕业务/视图中单独更改、更新，当您更换 dll 时更新将起作用。

• 使用所有组件，除了： Product.Windows.ViewModels Product.Windows.Models

Answer 3

1. 这有点矫枉过正，但我​​认为只有你可以保证你自己的程序。我想我会将 Contracts 放在 Common 和 Entities 中（取决于功能）。另外，我认为您不需要将 View 和 ViewModel 完全分开。如果它们在同一个项目中，它还将简化更改/调试过程。

2. 如果您的程序是客户端，那么您可以在 ViewModel 中使用 BL（至少在不太复杂的情况下）。如果你有一个主服务器和多个客户端，那么你不应该在你的 ViewModel 中实现 ANY 逻辑（除了化妆品），是的，创建一个新项目