c# - 架构师能说对吗 "MVVM only splits the code behind to multiple (3) files "

Question

我是 WPF 的新手，今天早上我与来自 C、C++ 背景的架构师进行了讨论。

我们正在尝试通过制作 PInvoke 创建一个依赖于 native dll 的视频通话应用程序。 WPF 应用程序主要是 UI，在后面的代码中，我们对视频/音频进行 Pinvoke 调用并列出可用的驱动程序。

因此，如果我们将数据视为来自数据库，那么我们的应用程序中涉及的“数据”并不多。

我们试图修改的 WPF 应用程序是 Boghe令人惊讶的是，他们也没有使用 MVVM。

虽然我热衷于实现 MVVM，但架构师认为它不必要地将文件分成 3 个部分。

He says if we want to change any thing in the view like changing a button or any control then it can be directly done in code behind. Why then use MVVM?

虽然我有理论上的答案，但还是忍不住同意他的观点。 他真的是对的吗？

Answer 1

He says if we want to change any thing in the view like changing a button or any control then it can be directly done in code behind. Why then use MVVM?

当然可以这样来做。问题是是否应该这样做。

对于相当小的代码库，您可能可以在代码隐藏中混合数据访问、核心逻辑和 UI 操作。然而，从长远来看，这不会产生可维护或可测试的代码，而且随着时间的推移，困惑可能会变得更糟，变成意大利面条代码。相信我的话，因为我工作的很大一部分时间都花在了扭转这些陈旧的烂摊子上。

在代码隐藏中混合一切的一些后果是:

• 从根本上违反“单一职责原则”(SRP) 的代码。
• 难以理解的代码，因为它在同一个地方做完全不同的事情。
• 容易破解的代码。我在这里更改了一些东西，但由于一些神秘的原因，那里的一些功能中断了。
• 代码重复/违反“不要重复自己”(DRY) 原则。您经常会在多个地方发现相同的逻辑。这是偶然的，还是故意的？如果我改变这里的逻辑，那里的相同/相似逻辑也必须改变吗？

请注意，除了第一点之外，这些都不是理论上的问题，而是您典型的“遗留”代码库中非常真实、直接的问题。

在我看来，说 MVVM 引入了更多代码隐藏类并不完全正确。这显然是一个不喜欢将数据、业务逻辑和 UI 逻辑层彼此隔离时关注点基本分离的人的声明:即使使用 MVVM，您也只有一个代码-课后听取您的意见。其他两个类(是的，可能还有两个)根本不能被视为“代码隐藏”，因为它们没有直接绑定(bind)到 View /设计器。