您放弃基于UserControl的WPF架构的MVVM有什么经验？

Question

我们使用Infragistics控件构建了一个基于Composite Application Library和MVVM的大型应用程序.

为了节省时间并使应用程序更直接,我们取消了MVVM要求.我们现在没有Presenters或ViewModel,我们的Views已经变成了简单的UserControls,它们是这样创建的:

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的事实之外,我只是经历了这个决定的积极影响,例如:

• 我们可以相互继承我们的非XAML UserControls
• 我们使用尽可能多的代码隐藏来加速开发
• 将infragistic控件直接附加到来自Web服务的模型类中,清除了我们将Infragistics与ObservableCollections绑定的几十个小约束问题
• 即使在直接的WPF中,ObservableCollections的缺乏也会导致无法创建简单菜单的问题消失
• 我们正在使用UserControls和后面的代码逐个替换EventAggregator与直接事件,这清除了事件的各种问题

有没有其他人在WPF中做MVVM有类似的经历？从长远来看,你遇到过任何真正的问题吗？

Answer 1

我们可以相互继承我们的非XAML UserControls

我不明白.那么MVVM会阻止继承吗？

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

只要代码与视图有关,代码隐藏就可以了.即.不是您想要测试的业务逻辑.分离关注点和所有问题.

您仍然可以在代码中执行所有操作时执行MVVM - 甚至是您的视图.MVVM并不是零代码.这是关于分离问题和从中获得的好处.如果您不需要在Blend中设计视图,那么无论如何您都可以将大部分或全部视图显示为代码.哎呀,即使你确实需要在Blend中工作,你的一些观点仍然可以表现为代码.您只需要评估权衡并做出有意识和明智的决策.

将infragistic控件直接附加到来自Web服务的模型类中,清除了我们将Infragistics与ObservableCollections绑定的几十个小约束问题

Infragistics控制非常差.在那里,我说了.如果是一个选项,请不要使用它们.如果它不是一个选项(我也一直在这个位置),你通常可以解决附加行为和其他技术的许多问题.这是一个麻烦,是的,但不要责怪MVVM - 责怪Infragistics产生一个与WPF平台不一致的控制集.

即使在直接的WPF中,ObservableCollections的缺乏也会导致无法创建简单菜单的问题消失

我根本不明白这一点.ObservableCollections是WPF的一部分,而不是MVVM.并且已经阅读了你的问题(再次 - 我在提交后不久回复了它)我会说这只是你对WPF如何工作的误解 - 与MVVM完全无关.

我们正在使用UserControls和后面的代码逐个替换EventAggregator与直接事件,这清除了事件的各种问题

正确工作的正确工具.如果您能够使用直接事件,那么无论您是否使用MVVM,都可以这样做.MVVM不以任何方式要求使用事件聚合器模式,因此您的观点再次不清楚.事件聚合器模式可用于确保不同组件可以在运行时协作,而不具有任何编译时依赖性.通过使用标准CLR事件,您可以在组件之间创建强大的依赖关系.你是否想要孤立地使用它们,你会有一点时间.

总之,对于MVVM来说,这并不是一个很大的例子,但更多的是缺乏理解.我想你正在上游游泳,我建议你仔细看看MVVM.它不是一个灵丹妙药或一刀切的模式,但它确实有助于为正确使用的WPF/SL应用程序创建一个梦幻般的基础.

Answer 2

我开始在这样的FFA(free-for-all)设计模式中进行WPF应用程序,即使对于小型项目,我也不会回头.虽然感觉你更有效率地走向源头,裸机用户界面,但我得出的结论是,它更像是对生产力的感知,因为你得到了即时的满足感.

考虑一下: TextBlock.Text = "HelloWorld".没有要构建的ViewModel,没有粘合V和VM或绑定设置.点击F5,我们看到了"HelloWorld"的所有荣耀.我的问题是多方面的.这是我最大的几个问题:

• 分离关注点.没有它,代码导航,错误修复,可扩展性和一般维护将受到严重阻碍.将一个功能添加到应用程序将更像是选择自己的冒险书或量子物理练习而不是实际完成任务.如果您有可预测的方式来构建应用程序,那么您可以采用可预测的方式来处理它.

  UI的灵活性.使用FFA模式时,我发现我在应用程序中设计UI的能力几乎是不可能的.太多次,我有一个我无法在Blend中设计的控件.它只会给出一个带有异常的红色边框.一些代码隐藏我使用了其他在设计模式下无法使用的问题导致问题.迁移到MVVM神奇地修复了我的所有Blend问题.如果我现在在Blend中获得红色边框,我知道 这是我的演示代码的问题.没有别的.

所以使用FFA可能会让你的V1快速出门,但是PHB会想知道为什么v1.5比v1要长四倍.我们都去过那里:)

我想如果你想做这样的事情,我会使用无视控件,你可以定义UI"PARTS",使它非常可混合.您可以通过OnApplyTemplate引用UI控件.这些控件完全可以设置并可继承.您可以在View中使用这些控件并从绑定中提取数据,并将其传递给您的无视控件.View,IMO应始终是VM绑定到这些控件的粘合剂.

对于Infragistics控件,您遇到问题,假设您使用Prism,则应为其创建自定义区域适配器.这使您可以完全编码如何将控件添加到Infragistics.没有约束力.一旦你内置了注入,视图注入将像你习惯的那样工作.

我已经看到有些人在MVVM中遇到过像这样的问题,但我相信它只是字面意义上的MVVM.并非一切都被信使所取代.我的~40视图(和不断增长的)应用程序有大约5个复合事件.我继承了控件,我使用视图注入甚至不是面板或内容控件的东西.有时我有代码隐藏处理演示文稿相关的代码/事件......而且......真的,我提倡MVVM而且我不给@ $&%关于测试:)

Answer 3

我尝试这样做,最终要回至 MVVM.你最终得到了在Windows Forms中总是最终得到的事件驱动的spagetti编码混乱.如果我再也不想做另一件事,myLabel.Text = this.MyLabelText我会很高兴.

不要误会我的意思 - MVVM很难坚持下去,你真的必须知道WPF才能把它拉下来.

但是,如果不使用它,你会失去很多,包括很多使用Expression Blend来设置控件和DataTemplates样式的能力.

Answer 4

我不同意这一点,我使用WPF,MVVM,WCF和Telerik控件开发了大规模的商务应用程序.一开始,使用MVVM有点困难但是一旦我们使用我们的设计和View模型框架,它变得非常容易.可重用性非常容易实现,开发时间也减少了.

而且完全改变控件真的很容易; 在某些地方我们使用了基本的WPF控件,我们后来用telerik控件替换了控件,反之亦然(因为在某些地方我们不需要像GridView这样的重型telerik控件).我可以说,如果需要,我们可以随时轻松地用其他一些第三方控件或本机WPF控件轻松替换所有telerik控件.

但是,是的,我们必须在使用telerik控件时实现一些变通方法,并在代码隐藏中编写一些代码来解决一些问题(telerik中的错误); 所有代码都是纯粹的表示逻辑.