MVVM毫无意义？
正统的MVVM实现是没有意义的吗？ 我正在创建一个新的应用程序，我认为Windows窗体和WPF。 我选择WPF是因为它具有面向未来的功能并提供了很大的灵活性。 代码更少，使用XAML可以更轻松地对UI进行重大更改。
由于WPF的选择是显而易见的，我认为我可以通过使用MVVM作为我的应用程序体系结构，因为它提供了可混合性，分离问题和单元可测试性。 理论上，它看起来很像UI编程的圣杯。 这个简短的冒险; 然而，变成了一个真正的头痛。 按照预期在实践中，我发现我已经为另一个交易了一个问题。 我倾向于成为一名执着的程序员，因为我想以正确的方式做事，这样我就可以获得正确的结果，并有可能成为更好的程序员。 MVVM模式刚刚在我的生产力测试中失败了，刚刚变成了一个大大的黑客攻击！
明确的例子是添加对Modal对话框的支持。 正确的方法是建立一个对话框并将其绑定到视图模型。 让这个工作很困难。 为了从MVVM模式中受益，您必须在应用程序的各个层的几个地方分发代码。 您还必须使用深奥的编程结构，如模板和lamba表达式。 东西，让你盯着屏幕抓你的头。 这使得维护和调试成为我最近发现的等待发生的噩梦。 我有一个关于框的工作正常，直到我第二次调用它时发生异常，并说它一旦关闭就不会再显示对话框。 我必须为对话框窗口添加一个关闭功能的事件处理程序，另一个在IDialogView实现中，最后在IDialogViewModel中添加另一个。 我认为MVVM会让我们摆脱这种奢侈的骇客！
有几个人在那里与这个问题竞争的解决方案，他们都是黑客，并没有提供一个干净，容易重用，优雅的解决方案。 大多数MVVM工具包都会遮盖对话框，当它们确实解决它们时，它们只是不需要自定义界面或视图模型的警报框。
我打算放弃MVVM视图模式，至少是它的正统实现。 你怎么看？ 如果您有任何问题，是否值得您付出麻烦？ 我只是一个无能的程序员，或者MVVM不是它被炒作到什么程度？
对不起，如果我的答案变得有点长，但不要责怪我！ 你的问题也很冗长。
总之，MVVM并非毫无意义。
明确的例子是添加对Modal对话框的支持。 正确的方法是建立一个对话框并将其绑定到视图模型。 让这个工作很困难。
是的，它确实是。
但是，MVVM为您提供了将UI的外观与其逻辑分开的方法。 没有人强迫你在任何地方使用它，没有人拿着枪对着你的额头，让你创建一个单独的ViewModel。
这是我对这个特定例子的解决方案：
ViewModel的业务并不属于用户界面处理特定输入的方式。 我会将代码添加到View的.xaml.cs文件中，该文件实例化对话框，并将其设置为其DataContext的相同ViewModel实例（如果需要，也可以是其他类型的实例）。
为了从MVVM模式中受益，您必须在应用程序的各个层的几个地方分发代码。 您还必须使用深奥的编程结构，如模板和lamba表达式。
那么，你不必在几个地方使用它。 这是我将如何解决它：
我认为MVVM的目的主要是分离应用程序的逻辑和具体的UI，因此可以轻松修改（或完全替换）UI。
我使用以下原则：View可以从ViewModel知道并假设它想要的任何东西，但ViewModel可以不了解视图。
WPF提供了一个很好的绑定模型，您可以使用它来实现这一点。
（顺便说一句，如果使用正确的话，模板和lambda表达式不是很深奥，但如果你不想，就不要使用它们。）
东西，让你盯着屏幕抓你的头。
是的，我知道这种感觉。 正是我第一次看到MVVM时的感受。 但是一旦你掌握了它，它就不会再感觉不好了。
我有一个关于盒子工作正常...
你为什么要把一个ViewModel放在关于盒的盒子后面？ 没有意义。
大多数MVVM工具包都会遮盖对话框，当它们确实解决它们时，它们只是不需要自定义界面或视图模型的警报框。
是的，因为一个UI元素在同一个窗口或另一个窗口中，或者正在轨道上运行的火星并不是ViewModel的关注点。
关注点分离
编辑：
这是一个非常好的视频，其标题是构建您自己的MVVM框架。 值得一看。
让这个工作很困难。 为了从MVVM模式中受益，您必须在应用程序的各个层的几个地方分发代码。 您还必须使用深奥的编程结构，如模板和lamba表达式。
对于一个普通的模态对话框？ 你当然在那里做错了什么 - MVVM的实现不一定非常复杂。
考虑到你对MVVM和WPF都是新手，很可能你在任何地方都使用次优解决方案，并且不必要地使事情复杂化 - 至少我在第一次访问WPF时就这么做了。 确保问题真的是MVVM，而不是放弃之前的实现。
MVVM，MVC，Document-View等是一个古老的模式家族。有缺点，但没有你描述的那种致命的缺陷。
我通过作弊来处理对话问题。 我的MainWindow实现了一个IWindowServices接口，它公开了所有特定于应用程序的对话框。 然后，我的其他ViewModel可以导入服务接口（我使用MEF，但您可以轻松地通过构造函数手动传递接口）并使用它来完成必要的操作。 例如，下面是我的一个小实用程序应用程序的界面：
//Wrapper interface for dialog functionality to allow for mocking during tests
public interface IWindowServices
{
bool ExecuteNewProject(NewProjectViewModel model);
bool ExecuteImportSymbols(ImportSymbolsViewModel model);
bool ExecuteOpenDialog(OpenFileDialog dialog);
bool ExecuteSaveDialog(SaveFileDialog dialog);
bool ExecuteWarningConfirmation(string text, string caption);
void ExitApplication();
}
这将所有的Dialog执行放在一个地方，它可以很容易地被用于单元测试。 我遵循该对话框的客户端必须创建适当的ViewModel的模式，然后可以根据需要进行配置。 执行调用块，然后客户端可以查看ViewModel的内容以查看对话框结果。
一个更纯粹的MVVM设计对于一个需要更清洁绝缘和更复杂组合的大型应用程序来说可能很重要，但对于中小型应用程序，我认为一种实用的方法，通过提供适当的服务来揭示所需的钩子， 。
链接地址: http://www.djcxy.com/p/56199.html上一篇: Is MVVM pointless?
下一篇: The best approach to create new window in WPF using MVVM