我正在一套应用程序中工作，这些应用程序在医疗保健环境中执行数据采集。我们的想法是拥有一个通用的基础架构（包括硬件IO，文件IO，通用域模型）和一个薄的顶层，每个健康专业的细节都有单独的项目。
模型层是一个富域模型，主要包含Domain数据类型。
在Model层的顶部，有Business层，主要处理工作流。例如，有一个CaptureConductor类，一个ICaptureDevice，一个IPlotterModel和一个IFileWriter类（每个来自域模型），并使它们协同工作。我还有AnalysisConductor，AnalysisReportModel，DeviceConfigurationConductor以及处理更高级别工作流程的其他类。
然后我有一些ViewModels，每个ViewModel都倾向于映射到Business层中的一个或几个对象（我认为它仍然是MVVM的“Model”部分）。因此，“SomeFeatureViewModel”映射到“SomeFeatureModel”，“OtherFeatureViewModel”映射到“OtherFeatureViewModel”等。
由于我使用的是MVVM框架（在这种情况下是MVVM Light），我决定将这种依赖关系“集中”在一个项目中，因此我创建了一个包含许多不相关的ViewModel的ViewModel项目。
所以我的问题是：这是一个很好的分区吗？
一方面，在执行此操作（水平分区）时，我将框架依赖关系集中在ViewModel层及更高层中，因此Model层可以是“纯粹的”。但这给了我低凝聚力（ViewModel项目包含许多不相关的东西）和高耦合（每次我需要一个ViewModel，我需要引用那个大项目。
另一方面，如果我垂直分区，也就是说，我让View和ViewModel在每个项目中共存，按功能分组，我得到了更好的（IMO）内聚和更低的耦合，其缺点是引用框架几乎在每个项目中都有。
答案 0 :(得分：1)
我认为您必须根据SRP将功能组合在一起。我认为在大多数情况下ViewModel倾向于与View一起更改，因此它们应该放在一个包中。
您的ViewModel项目感觉与我断开了联系。它既不是您的软件的UI层，也不是业务逻辑层。它是一个UI，在未知原因上与它分开。
另外我认为您的不同项目可能需要将不同的ViewModel连接到单个Model，对吗？
因此，我认为您的业务逻辑层应该是一个框架。 View s + ViewModel应该是每个健康专业的不同项目。如果需要，这些项目可以扩展您的框架。
这可以满足您的需求吗？
答案 1 :(得分：0)
如果可能，尝试将ViewModel分区为几个具有相关ViewModel的项目。这将提高一些凝聚力和降低整体耦合。