您放弃 MVVM 而采用基于 UserControl 的 WPF 架构有何体验？

我们基于以下内容构建了一个大型应用程序复合应用程序库 and MVVM using 基础设施学控制。

为了节省时间并使申请更加直接，我们废除了 MVVM 要求。我们现在没有 Presenter 或 ViewModel，我们的 View 已成为简单的 UserControl，其创建方式如下：

基本编辑器.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;
        }
    }
}

客户编辑器.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“感觉很脏”这一事实之外，我还只经历了积极的影响根据该决定，例如：

• 我们可以互相继承非 XAML UserControls
• 我们使用尽可能多的代码隐藏来加快开发速度
• 将 Infragistic 控件直接附加到来自 Web 服务的模型类，解决了我们在将 Infragistics 绑定到 ObservableCollections 时遇到的许多小绑定问题
• 即使在直接的 WPF 中，缺少 ObservableCollections 也会带来类似的问题无法创建简单的菜单 go away
• 我们正在使用 UserControls 和代码隐藏将 EventAggregator 逐一替换为直接事件，这解决了事件的各种问题

在 WPF 中做 MVVM 的其他人有类似的经历吗？从长远来看，您遇到过任何实际问题吗？

我们可以互相继承非 XAML UserControls

我不明白。 MVVM 会阻止继承吗？

我们使用尽可能多的代码隐藏来加快开发速度

只要代码与视图有关，隐藏代码就可以。 IE。不是您要测试的业务逻辑。关注点与全部分离。

您仍然可以在代码中执行所有操作的同时执行 MVVM - 甚至是您的视图。 MVVM 并不是零代码隐藏。这是关于分离关注点和从中获得的好处。如果您不需要在 Blend 中设计视图，那么无论如何您都可以将大部分或全部视图显示为代码。哎呀，即使你do当您需要在 Blend 中工作时，您的一定量的视图仍然可以表现为代码。您只需要评估权衡并做出明智且明智的决定。

将 Infragistic 控件直接附加到来自 Web 服务的模型类，解决了我们在将 Infragistics 绑定到 ObservableCollections 时遇到的许多小绑定问题

基础设施控制非常差。在那里，我说了。如果这是一个选项，请不要使用它们。如果这不是一个选择（我也曾处于这个位置），您通常可以通过附加行为和其他技术来解决许多问题。是的，这很麻烦，但不要责怪 MVVM - 责怪 Infragistics 生成了与 WPF 平台如此不一致的控件集。

即使在直接的 WPF 中，缺少 ObservableCollections 也会导致无法创建简单菜单等问题

我根本不明白这一点。 ObservableCollections 是 WPF 的一部分，而不是 MVVM。读完你的问题（再次 - 我在你提交后不久就回复了它）我想说这只是你对 WPF 如何工作的误解 - 与 MVVM 完全无关。

我们正在使用 UserControls 和代码隐藏将 EventAggregator 逐一替换为直接事件，这解决了事件的各种问题

正确的工具适合正确的工作。如果您能够使用直接事件，那么无论您是否使用 MVVM，都可以这样做。 MVVM 不以任何方式要求使用事件聚合器模式，所以你的观点又不清楚。事件聚合器模式可用于确保不同的组件可以在运行时进行协作，而无需任何编译时依赖性。通过使用标准 CLR 事件，您可以在组件之间创建强依赖性。如果你想单独使用它们，你会遇到麻烦的。

总而言之，这并不是对 MVVM 的反对，更多的是缺乏理解。我认为你正在逆流而上，我建议你仔细看看 MVVM。它不是灵丹妙药或一刀切的模式，但如果正确使用，它肯定可以帮助您为 WPF/SL 应用程序创建一个梦幻般的基础。