将一个项目拆分为两个独立的MVVM子项目是否正确答案

【问题标题】：Is it correct splitting one project into two independent MVVM sub-project将一个项目拆分为两个独立的MVVM子项目是否正确
【发布时间】：2015-04-02 07:34:31
【问题描述】：

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

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

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

上述思路利用了重组对未来发展的影响，因此我们考虑将当前项目一分为二：

UI 项目 - 包含和管理当前和未来的 UI 代码（视图和视图模型）。
逻辑项目 - 包含和管理当前和未来的逻辑代码（模型）。

应用这种拆分是否正确？对未来的开发、调试和测试来说会不会过大？

【问题讨论】：

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

标签： wpf mvvm architecture structure

【解决方案1】：

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

【讨论】：

我继续通过您的回答与三个独立的项目（视图、视图模型、模型）进行开发。您的想法给了我一个完整的分离，因此如果我不小心在 ViewModel 类中编写视图代码可能会破坏MVVM 模式，它不会发生，我会得到编译错误，因为我的 ViewModel 项目实际上没有对 View 代码的合适引用。非常感谢您的回答。

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

未来发展

未来开发最好将项目拆分，因为业务逻辑的改变可以在不触及UI项目的情况下进行。

调试

今天的调试工具可以毫无限制地处理这个问题。

测试

通常您可以对测试进行相同的拆分。如果您为逻辑项目中的所有功能进行单元测试，则除 UI 之外的所有内容都将涵盖。

这意味着，拆分项目始终是更好的选择。

【讨论】：