我是WPF的新手，今天早上我和我的架构师进行了讨论，他来自C，C++背景。
我们正试图通过制作PInvoke来创建一个依赖于本地dll的视频呼叫应用程序。WPF应用程序主要是UI，在代码背后，我们对视频/音频进行Pinvoke调用，并列出可用的驱动程序。
因此，如果我们谈论的是来自数据库的数据，那么在我们的应用程序中就没有太多"Data"。
我们试图修改的WPF应用程序是Boghe，令人惊讶的是，他们也没有使用MVVM。
虽然我热衷于实现MVVM，但架构师认为它不必要地将文件拆分为3个部分。
他说，如果我们想更改视图中的任何东西，比如更改按钮或任何控件，那么可以直接在代码后面完成。为什么要使用MVVM？
虽然我有理论上的答案，但我还是同意他的观点他真的对吗
他说，如果我们想更改视图中的任何东西，比如更改按钮或任何控件，那么可以直接在代码后面完成。为什么要使用MVVM？
当然，可以这样做。问题是是否应该这样做。
对于一个相当小的代码库，您可能会在代码背后混淆数据访问、核心逻辑和UI操作。然而，从长远来看，这将不会产生可维护或可测试的代码，而且随着时间的推移，混乱可能会变得更糟，并变成意大利面条式的代码。相信我的话，因为我工作的大部分时间都花在了扭转这种旧局面上。
将代码中的所有内容混合在一起的一些后果是：
- 根本违反"单一责任原则"（SRP）的准则
- 代码很难理解，因为它在同一个地方做着非常不同的事情
- 容易破解的代码。我在这里更改了一些东西，出于某种神秘的原因，那里的一些功能中断了
- 代码重复/违反"不要重复自己"（DRY）原则。你经常在几个地方找到相同的逻辑。这是偶然的，还是故意的？如果我改变这里的逻辑，那里相同/相似的逻辑也必须改变吗
请注意，除了第一点之外，这些都不是理论上的问题，而是典型的"遗留"代码库中非常真实、直接的问题。
在我看来，MVVM在类后面引入更多代码的说法并不完全正确。这显然是一个不理解当您将数据、业务逻辑和UI逻辑层彼此隔离时所产生的基本问题分离的人的声明：即使使用MVVM，您的视图也只有一个代码隐藏类。另外两个类（是的，可能还会有两个）不能被视为"代码隐藏"，因为它们没有直接绑定到视图/设计器。
简短回答：不！ViewModels与不同文件中的Codebehin不同。
有了正确的MVVM实现，您就没有代码绑定，或者至少没有一个很小的。
但在ViewModel中，您不能像在MVVM中那样直接访问窗口ViewModel和View之间的通信是通过绑定完成的没有直接引用视图（通常）。
与以视图为中心的方法相比，MVVM带来了一些巨大的优势。它是可测试的，它更容易更改，它是一个适配器。。。
编辑如果他真的是你的软件架构师，他应该更清楚。。。至少这是我对软件架构师的期望
我也同意stakx和Mare Infinitus；MVVM提供了很多好处，而不仅仅是创建多个代码隐藏文件。
根据我的经验，MVVM是学习和使用WPF功能的最佳方式，它鼓励并迫使您使用WPF的功能，如Binding、Commands、Styles、Converters等
除了UnitTesting（我认为这在您的应用程序中非常重要）、可重用性等之外，使用MVVM的一个非常重要的好处是它可以支持多个视图，即您可以为应用程序拥有多个UI，所有这些UI都可以使用相同的ViewModels；这对你来说可能不是一个要求，但你可能需要在几年后拥有一个新的接口，或者在未来支持Silverlight或Metro等其他平台，在这种情况下，MVVM将为你节省很多精力。
我建议你阅读这篇文章，它解释了MVVM的真正好处，并解释了其他所谓的好处（尽管我觉得它们在实践中是真正的好处）-MVVM Backlash
一个目的是你可以在没有视图的情况下对你的视图逻辑（视图模型）进行单元测试。
以下是Rachel关于视图模型优先方法的一条很好的评论：
请记住，使用MVVM，ViewModels就是您的应用程序。视图是只是一个漂亮的界面，允许用户与您的ViewModels。
如果项目中只有两个人，而且每个人都是一体的，那么他是对的。
但如果你不想让设计人员把控制器（或ViewModel）搞砸，或者不想让程序员把视图改成什么样子，你知道，就像程序员做设计一样。
此外，您可以在不搜索大量文本文件的情况下，立即在哪里进行更改。
此外，MVVM或MVC的分离是编程的基本原则之一，它是数据逻辑视图分离，如果架构师说你不这样做，可能是时候问另一个架构师了：）