.net 在代码隐藏中使用表示模型的主要缺点是什么？

我正在努力准备接受这个问题的挑战：

“为什么我们不能在代码隐藏中实现表示模型？”

事实上，我曾经参与过一个项目，我们使用了一个在代码隐藏中实现的表示模型。它工作得相当好，我们甚至可以对它进行单元测试。是的，您在单元测试中依赖WPF。。。但它确实有效

那么，使用代码隐藏的主要缺点是什么

---

我确实更喜欢独立ViewModel（MVVM）的想法，但目前我觉得无法向客户证明这一点。

您回答了问题的第一部分，必须在单元测试期间引导wpf应用程序。另一个是可移植性，您是否希望能够将不同的视图实现附加到相同的表示模型。（我知道，但这是你的全部）

---

还有技能集的分离，只有了解xaml的开发人员才会参与视图的实际创建。允许您利用不了解wpf的现有内部人才。

简单的答案是。当然，有人可能会说，通过将表示模型放在代码后面，它与视图（XAML）是分开的，但我不同意这种说法。代码隐藏可以“查看”视图的所有内部细节，因为它是视图。xaml和代码隐藏一起编译成一个类，成为视图。它们根本不是分开的

有很多例子需要深入到代码背后去做与视图相关的事情，比如连接控件之间的交互，而这些控件在Xaml中是无法指定的。一旦您这样做了，您现在就可以将视图逻辑与表示逻辑混合在一起了

---

ViewModel的概念非常强大。ViewModels可以相互“交谈”，而视图之间不会“交谈”，甚至ViewModels也不会“知道”任何有关视图的信息。

查看这两个视频了解一些信息。这两个视频都展示了从代码隐藏中的所有内容开始开发应用程序，然后重构为MVVM模式

• （事实上总共有10个视频，至少检查第一个和第二个）

---

此外，有关更多链接，请参见此SO问题：

当您首先使用ViewModel方法时，这将成为一个缺点。在主应用程序中，实例化ViewModel对象图，将其分配给根视图datacontext，然后让视图根据ViewModel通知呈现其相关子视图

为什么这是一个缺点？事实上，你可以在后台使用你的代码，但你最终会得到一个反弹，有时你应该这样做。 但实际上，这种方法是理想的，在这种情况下，您的viewmodel完全不受影响，甚至您可以通过先编程后编程来逆转您的开发过程。（开玩笑）

另一方面，如果您使用先查看的方法，则不会有任何缺点，因为viewmodel位于该方法之上。因为控件仍然在视图中，如果您需要一些棘手的东西，比如使用密码框，那么就自然地这样做，就像Microsoft命中注定的那样

---

希望能有所帮助。

不错，但到目前为止，我没有发现任何令人信服的答案。。。这似乎有很大的心理方面。大概有了纪律代码后就可以了？我想这将是一个很好的方法来迫使不那么资深的开发人员做正确的事情thing@Schneider以同样的方式，你可以用C语言来编写面向对象的代码，而不是C++或C语言，是的，它会很好。