WPF-MVVM体系结构(Visual Studio解决方案和项目)

本文关键字：项目 解决方案 Studio 体系结构 Visual WPF-MVVM | 更新日期: 2023-09-27 18:12:17

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

  • wpf-winapp有一个本地数据库，还连接到REST服务
  • 开发时间并不是最关心的问题；但是可维护性和可测试性
  • 将使用IOC容器和DI
  • 计划执行1个视图模型对1个视图
  • 我不想使用任何WPF/MVVM框架，因为这是我第一次使用WPF-MVVM应用程序(就像第一次使用裸DOM javascript编码一样，即使有jquery(

我决定使用多个项目，到目前为止我提出了以下内容：

  1. 产品.WindowsCommon(Utils、日志记录、帮助程序等(
  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. 产品.Windows.Models(INPChanged(
  8. Product.Windows.ViewModels(INPChanged和ICommands(
  9. 产品.Windows.Tests(单元测试(

我只想问：

  1. 这个体系结构是不是有点过头了？

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

提前感谢：(

WPF-MVVM体系结构(Visual Studio解决方案和项目)

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

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

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

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

我最近看了罗伯特·马丁的演讲。据我所知，他曾说过，应用程序的体系结构应该反映应用程序的功能。类不应分组在名为(MVC或MVVM(的项目或文件夹中。这个告诉我们应用程序的功能。类应该根据它们的作用和实现的特性进行分组。我还没有到这个阶段。我仍然像你一样对事物进行分组：(。

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

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

  • 使用除以下组件之外的所有组件：产品.窗口.视图模型产品.窗口.模型

  1. 这有点过头了，但我认为只有你才能为自己的计划担保。我想我会把合同放在通用和实体中(取决于功能(。此外，我认为您不需要在View和ViewModel之间完全分离。如果他们在同一个项目中，这也将简化更改/调试过程。

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

相关文章：