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

我正在MVVM模式中开发Window-App WPF项目。目前，该应用程序有点简单（不能真正解释产品的性质），但最终它有望成为更复杂的应用程序。WPF - MVVM体系结构（Visual Studio解决方案和项目）

wpf winapp有一个本地数据库，也连接到一个REST服务。
开发时间并不是真正的首要关注点;但可维护性和可测试性。
将使用一个IOC容器和DI
规划做1视图模型是：1个浏览
我不希望使用任何WPF/MVVM框架，因为这是我在WPF的MVVM应用程序第一次（就像第一次在裸露的DOM中编写javascript一样，即使有jquery也是如此）。

我决定使用多个项目，这里就是我想出迄今：

Product.Windows.Common（utils的，记录，助手等）
产品.Windows.Entities（数据库和REST实体）
Product.Windows.Contracts（所有接口将驻留在此名称空间/项目中）
Product.Windows.Data（本地数据库）
Product.Windows.ServiceClients（为REST客户端）
Product.Windows.App（主WPF项目，包含了浏览/ XAML ）
Product.Windows.Models（INPChanged）
Product.Windows.ViewModels（INPChanged和个ICommand）
Product.Windows.Tests（单元测试）

我只想问：

是这种架构有点过杀人？
我是否需要为业务逻辑创建一个Product.Windows.Business？或者我应该把商业逻辑放在ViewModels中？

预先感谢您:)

来源

2014-07-09 JL Dajoyag

*很多很好的问题基于专家的某种程度的意见经验，但对这个问题的回答往往几乎完全基于意见，而不是事实，参考或具体的专业知识。*因此，我已投票结束这个问题。 – Sheridan

我目前工作的一个应用程序具有相似的结构。项目结构看起来不错。在我的项目中，我做了一些不同的事情。

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

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

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

我最近查看了Robert Martin的演示文稿。从我记得的他说，应用程序的架构应该尖叫应用程序的功能。不应将类分组到名为（MVC或MVVM）的项目或文件夹中。这告诉我们什么应用程序没有做什么。应该按照他们所做的功能来分类。我还没有在这个阶段。我仍然像你一样分组:)。

我看到你只有一个测试项目。如果你在这个项目中为你打算测试的所有程序集添加目录，这也可能没问题。如果你没有这样做，那么找到特定装配的测试会有点困难。您可能需要为计划测试的每个装配添加测试项目。

来源

2014-07-09 07:10:51

谢谢@flo_badea的想法:) p2 - 很好，我们同意数据和服务客户端。 p3 - 是的，计划将安全性通用。我可能仍然会继续使用，在应用程序和帮助程序上使用DI（对于未来可能会有多种实现） p4 - 感谢将它们结合起来的想法。也会考虑这个问题 p5 - 关于它的伟大想法！ p6 - yup，计划在测试项目中为每个程序集添加文件夹。 –

一想到，我认为你是对的。我将切换到使用静态方法将utils/helpers作为类。 –

我的意思是utils是这些utils类通常包含静态方法。根据我读过的这是由于设计不足。我会给你作为我的治疗项目的例子。到目前为止它不包含任何utils类。顺便说一句，我没有提到这一点，你应该尝试使用DI，如果你感觉舒服。我在我目前的项目中也是这样做的。这是我第一个将DI应用于一切的项目，它的接缝效果非常好。该应用程序也是高度可测试的。 –

你可以组织你的组件，只要你想，但我prefere以下结构： - 的创建项目中的每个画面2类库（DLL）（一个他们有这个屏幕的视图+视图模型，其他DLL有它的业务逻辑），所以你可以使用你的视图和视图模型与另一个业务逻辑，也可以更改，更新每个屏幕业务/视图分开，更新将当你更换一个DLL时工作。

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

来源

2014-07-09 07:07:50

实际上，人们不会在另一个应用程序中重新编译_same_视图和_same_视图模型。您的视图为您的演示模式量身定制，您的视图模型针对您的应用程序逻辑和数据模型量身定制。应用程序之间共享的空间很小。 – Gusdor

好吧，在我的情况下，我在应用程序之间共享屏幕视图，但是您可以为每个屏幕使用一个dll（视图+ viewmodel + business）。 –

我有超过25种不同的意见。我真的想要25个dll吗？ – Gusdor

这是有点矫枉过正，但我认为只有你可以担保自己的程序。我想我会把合同里面共同和实体（根据功能）。另外，我认为你不需要在View和ViewModel之间完全分开。如果他们在同一个项目上，它还可以简化更改/调试过程。
如果你的程序只是客户端，你可以在ViewModel中使用BL（至少如果它没有太复杂的话）。如果你有一个主服务器和多个客户端，那么你不应该在你的ViewModel实施任何逻辑（除化妆品），并且是创建一个新项目

来源

2014-07-09 07:15:25

谢谢！＃1 - 好主意，我将模型和视图模型合并到主要的WPF应用程序中（很像控制器在ASP.NET MVC项目中的方式）＃2 - 这是客户端，因此对ViewModel内部的逻辑有1票。 –

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

回答

相关问题