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）。 / LI>

我决定使用多个项目，这是我到目前为止所做的：

1. Product.Windows.Common （Utils，Logging，Helpers等）
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 ？或者我应该将业务逻辑放在ViewModels中吗？

提前谢谢你：）

Answer 1

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

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

很好，日志记录是单独实现的，如果你有安全性，这也应该在Common中实现。从我最近阅读的一本很好的书，.NET中的依赖注入，utils＆amp;助手是设计不佳/不完整的结果。这些类通常包含静态方法。但我不认为这与讨论有关。

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

我最近看过Robert Martin的演讲。从我记忆中他说，应用程序的架构应该尖叫应用程序的功能。不应将类分组到称为（MVC或MVVM）的项目或文件夹中。这告诉我们应用程序的功能。类应该按照它们的功能，按照它们实现的功能进行分组。我还没有进入这个阶段。我仍然像你一样分组:)。

我发现你只有一个测试项目。如果在此项目中为计划测试的所有程序集添加目录，这也可能没问题。如果您不这样做，那么找到特定组件的测试会有点困难。您可能希望为计划测试的每个程序集添加测试项目。

Answer 2

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

• 使用所有组件，但以下情况除外： Product.Windows.ViewModels Product.Windows.Models

Answer 3

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

2. 如果您的程序只是客户端，那么您可以在ViewModel中拥有BL（至少如果它不太复杂，可以遵循）。如果您有一个主服务器和多个客户端，那么您不应该在ViewModel中实现 ANY 逻辑（化妆品除外），并且是创建一个新项目