把一个项目分成两个独立的MVVM子项目，对吗？

Question

我目前正在致力于一个大型的WPF项目，这个项目已经被开发和结构化，而且它预计还会增长。但是，它没有任何MVVM模式体系结构组件。

我们现在的目标之一是重组包含的UI，以支持MVVM模式组件。

由于MVVM视图层开发分离的设计，删除了几乎所有的UI“代码隐藏”，我们提出了上述思想。

上述想法利用了重组对未来发展的优势，因此我们考虑将当前的项目分成两部分：

• UI项目-包含和管理当前和未来的UI代码(视图和ViewModels)。
• 逻辑项目-包含和管理现在和未来的逻辑代码(模型)。

实行这种分割是正确的吗？对于未来的开发、调试和测试来说，这会不会有些过分呢？

Answer 1

我不认为你的提议有什么问题。如果您遵循MVVM模式“正确”，那么它应该提供视图和ViewModels之间的完全分离。因此，将所有视图放在一个单独的项目中到您的ViewModels中也是有意义的。在没有视图的情况下，您的ViewModels应该都能很好地工作，从而使UI生产任务和逻辑生产任务之间有一个非常清晰的分离。您的视图可以使用设计时数据来模拟ViewModels的行为，而不需要实际存在任何逻辑。

Answer 2

将业务逻辑分解为另一个项目是一个非常好的主意，该项目将被构建为一个DLL。在此之后，您可以在另一个前端应用程序(例如，Web项目)中重用所有业务逻辑。在此之后，您可以利用MVVM模式来替换前端部分并重用逻辑部分。

未来发展

对未来的开发来说，更好的做法是拆分项目，因为可以在不触及UI项目的情况下对业务逻辑进行更改。

Debug

今天的调试工具可以不受任何限制地处理这个问题。

测试

通常，您可以对测试进行同样的拆分。如果您对逻辑项目中的所有功能进行单元测试，那么除了UI之外，所有内容都会被覆盖。

这意味着，项目分割永远是更好的选择。

Answer 3

我们使用棱镜，我们的视图和视图模型分成5个单独的项目，更不用说其他项目(基础设施、数据层等)。我们使用棱镜来管理这5个(其中4个是棱镜模块- wpf类库)，其中一个是主要的wpf项目，它将其他模块加载到一个shell中。