MVVM 解决方案结构：项目分区应该是垂直的（按功能）还是水平的（按层）？答案

【问题标题】：MVVM solution structure: should project partition be vertical (by feature) or horizontal (by layer)?MVVM 解决方案结构：项目分区应该是垂直的（按功能）还是水平的（按层）？
【发布时间】：2015-12-07 19:18:12
【问题描述】：

我正在使用一套在医疗保健环境中执行数据采集的应用程序。这个想法是拥有一个通用的基础架构（包括硬件 IO、文件 IO、通用域模型）和一个瘦顶层，其中包含针对每个健康专业的具体项目的单独项目。

模型层是一个富域模型，主要包含域数据类型。在模型层之上是业务层，主要处理工作流。例如，有CaptureConductor 类，采用ICaptureDevice、IPlotterModel 和IFileWriter 类（每个都来自域模型），并使它们一起工作。我还有 AnalysisConductor、AnalysisReportModel、DeviceConfigurationConductor 和其他处理更高级别工作流的类。

然后我有一些 ViewModel，其中每个都倾向于映射到来自业务层的一个或少数几个对象（我认为它们仍然在 MVVM 的“模型”部分中）。所以，“SomeFeatureViewModel”映射到“SomeFeatureModel”，“OtherFeatureViewModel”映射到“OtherFeatureViewModel”等等。

由于我使用的是 MVVM 框架（在本例中为 MVVM Light），因此我决定将这种依赖关系“集中”在一个项目中，因此我创建了一个包含许多有些不相关的 ViewModel 的 ViewModel 项目。

所以我的问题是：这是一个好的分区吗？

一方面，在这样做（水平分区）时，我将框架依赖集中在 ViewModel 层及以上，因此模型层可以是“纯”的。但这给了我低内聚（ViewModel 项目包含许多不相关的东西）和高耦合（每次我需要一个 ViewModel，我都需要引用那个大型项目。

另一方面，如果我垂直分区，也就是说，我让 View 和 ViewModel 在每个项目中一起存在，按功能分组，我会获得更好的 (IMO) 内聚和更低的耦合，缺点是引用框架几乎在每个项目中。

【问题讨论】：

标签： mvvm architecture solution

【解决方案1】：

我认为您必须根据SRP 将功能组合在一起。我认为在大多数情况下ViewModel 倾向于与View 一起更改，因此它们应该放在一个单独的包中。

您的ViewModel 项目对我来说感觉有些脱节。它既不是软件的 UI 层，也不是业务逻辑层。它是一块 UI，不知为何与它分离。

另外我认为你的不同项目可能需要不同的ViewModels 连接到一个Model，对吧？

所以，我认为您的业务逻辑层应该是一个框架。 Views + ViewModels 应该是每个健康专业的不同项目。如果需要，这些项目可以扩展您的框架。

这是否满足您的需求？

【讨论】：

感谢您的回答！实际上，每个健康专业都会以不同的方式呈现相同的捕获数据（因此用户可以对数据执行特定于专业的操作），但数据捕获的底层传导无论从何种效果来看，专业之间都是相同的。这就是为什么我将 ViewModel 作为给定模型的 包装器（一对一关系），而每个特定应用程序将具有不同的 View（一对多 ViewModel/Views 关系）。你认为这有意义吗？
（提炼之前的评论）例如，我目前将 CaptureModel 和 CaptureViewModel 重构为一个名为 CaptureService 的项目，以便每个处理数据捕获的应用程序都可以引用这个“服务" 包含模型（业务逻辑）的程序集，它包装了 ViewModel（一个基于数据绑定的外观到不同的可能视图）。

【解决方案2】：

如果可能，请尝试将您的 ViewModel 划分为多个具有相关 ViewModel 的项目。这将在一定程度上提高内聚力并降低整体耦合度。

【讨论】：