放弃基于 UserControl 的 WPF 架构的 MVVM 是什么体验? [英] What is your experience with abandoning MVVM for UserControl-based WPF architecture?
问题描述
我们使用基础设施控件基于复合应用程序库和MVVM构建了一个大型应用程序.
We built an large application based on Composite Application Library and MVVM using Infragistics controls.
为了节省时间并使应用程序更直接，我们取消了 MVVM 要求.我们现在没有演示者或视图模型，我们的视图变成了简单的用户控件，它们是这样创建的:
In order to save time and make the application more straight-forward, we scrapped the MVVM requirement. We now have no Presenters or ViewModels and our Views have become simple UserControls which are created like this:
BaseEditor.cs:
using System.Windows.Controls;
namespace App
{
public class BaseEditor : UserControl
{
public string Title { get; set; }
public BaseEditor()
{
Title = "This was defined in the Base Editor.";
Loaded += new System.Windows.RoutedEventHandler(BaseEditor_Loaded);
}
void BaseEditor_Loaded(object sender, System.Windows.RoutedEventArgs e)
{
StackPanel sp = new StackPanel();
TextBlock tb = new TextBlock();
tb.Text = Title;
sp.Children.Add(tb);
this.Content = sp;
}
}
}
CustomerEditor.cs:
namespace App
{
public class CustomerEditor : BaseEditor
{
public CustomerEditor()
{
Title = "This was overwritten by the CustomerEditor.";
}
}
}
Window1.cs.xaml:
<Window x:Class="App.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:App"
Title="Window1" Height="300" Width="300">
<Grid>
<local:CustomerEditor/>
</Grid>
</Window>
除了可测试性问题以及像这样执行 WPF 的感觉很脏"这一事实之外，我只经历了这个决定的积极影响，例如:
Apart from the testability issue and the fact that this "feels dirty" doing WPF like this, I have only experienced positive effects from this decision, e.g.:
- 我们可以相互继承我们的非 XAML 用户控件
- 我们使用尽可能多的代码隐藏来加快开发速度
- 将基础设施控件直接附加到来自 Web 服务的模型类，解决了我们在将基础设施与 ObservableCollections 绑定时遇到的许多小绑定问题
- 即使在直接的 WPF 中，ObservableCollections 的缺乏也会产生像 无法创建一个简单的菜单走开
- 我们正在使用 UserControls 和背后的代码将 EventAggregator 一一替换为直接事件，从而解决了事件的各种问题
有没有其他人在 WPF 中做 MVVM 有类似的经历?从长远来看，您是否遇到过任何实际问题?
推荐答案
我们可以相互继承我们的非 XAML 用户控件
we can inherit our non-XAML UserControls from each other
我不明白.MVVM 会排除继承吗?
I don't understand. What about MVVM precludes inheritance?
我们使用尽可能多的代码隐藏来加快开发速度
we use as much code-behind as we want which expedites development
代码隐藏没问题，只要它是与视图相关的代码.IE.不是您要测试的业务逻辑.分离关注点和所有.
Code-behind is fine as long as it's code that is concerned with the view. ie. not business logic that you want to test. Separation of concerns and all.
您仍然可以在使用代码执行所有操作的同时执行 MVVM - 甚至是您的视图.MVVM 不是关于零代码背后的问题.这是关于分离关注点和从中获得的好处.如果您不需要在 Blend 中设计您的视图，那么您无论如何都可以将大部分或全部视图显示为代码.哎呀，即使您确实需要在 Blend 中工作，您的视图仍有一定数量可以显示为代码.您只需要评估权衡并做出有意识和明智的决定.
You can still do MVVM whilst doing everything in code - even your view. MVVM is not about zero code behind. It's about separating concerns and the benefits you derive from that. If you have no need to design your views in Blend, then by all means you can manifest much or all of the view as code. Heck, even if you do need to do work in Blend, there's a certain amount of your view that could still be manifested as code. You just need to evaluate the trade-offs and make conscious and informed decisions.
将基础设施控件直接附加到我们来自 Web 服务的模型类，解决了我们在将基础设施与 ObservableCollections 绑定时遇到的许多小绑定问题
attaching the infragistic controls directly to our model class coming from the web service cleared up dozens of little binding problems we were having with binding Infragistics to ObservableCollections
基础设施控制非常差.在那里，我说了.如果这是一种选择，请不要使用它们.如果它不是一个选项(我也一直处于这个位置)，您通常可以解决附加行为和其他技术的许多问题.是的，这很麻烦，但不要怪 MVVM - 怪 Infragistics 生成与 WPF 平台如此不一致的控制集.
The Infragistics controls are extremely poor. There, I said it. If it's an option, don't use them. If it is not an option (and I've been in this position too), you can normally work around many issues with attached behaviors and other techniques. It's a hassle, yes, but don't blame MVVM - blame Infragistics for producing a control set that is so at odds with the WPF platform.
即使在直接的 WPF 中，ObservableCollections 的缺乏也会使诸如无法创建简单菜单之类的问题消失
even in straight WPF, the lack of ObservableCollections make problems like not being able to create a simple Menu go away
我完全不明白这一点.ObservableCollections 是 WPF 的一部分，而不是 MVVM.并阅读了您的问题(再次 - 我在您提交后不久回复了它)我想说这只是您对 WPF 如何工作的误解 - 与 MVVM 完全无关.
I don't understand this point at all. ObservableCollections are part of WPF, not MVVM. And having read your question (again - I replied to it not long after you submitted it) I'd say this is just your misunderstanding of how WPF works - nothing to do with MVVM at all.
我们正在使用 UserControls 和背后的代码将 EventAggregator 一一替换为直接事件，从而清除了事件的各种问题
we are replacing the EventAggregator one-by-one with direct events using UserControls and code behind, which cleared up all kinds of problems with events
适合工作的合适工具.如果您能够使用直接事件，那么无论您是否使用 MVVM，都可以这样做.MVVM 在任何情况下都不需要使用事件聚合器模式，因此您的观点再次不清楚.事件聚合器模式可用于确保不同的组件可以在运行时协作，而无需任何编译时依赖项.通过使用标准 CLR 事件，您可以在组件之间创建强依赖关系.如果您想单独使用它们，那么您将非常有时间.
Right tool for the right job. If you're able to use direct events, then you can do so whether you're using MVVM or not. MVVM does not in any way require the use of the event aggregator pattern, so again your point is unclear. The event aggregator pattern can be used to ensure that different components can collaborate at runtime without having any compile-time dependencies. By using standard CLR events, you're creating strong dependencies between your components. Should you ever want to use them in isolation, you're gonna have one heck of a time.
总而言之，这并不是反对 MVVM 的理由，而是缺乏理解.我认为您正在上游游泳，我建议您仔细研究 MVVM.它不是灵丹妙药或一刀切的模式，但如果使用得当，它肯定有助于为您的 WPF/SL 应用程序创建出色的基础.
In summary, this doesn't much of a case against MVVM, but more a lack of understanding. I think you're swimming upstream and I'd advise you to take a closer look at MVVM. It's not a silver bullet or one-size-fits-all pattern, but it can sure help create a fantastic basis for your WPF/SL applications when used correctly.
这篇关于放弃基于 UserControl 的 WPF 架构的 MVVM 是什么体验?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
