如何有效地编写WPF？

Question

当我第一次了解微软当时用于开发桌面应用程序的新框架WPF时，我认为它的最大好处之一就是它的效率。毕竟，我已经知道我想要使用的GUI控件和元素是什么 - 我只需要在页面上将它们全部打开，然后将所有绑定连接起来，我就完成了。之后，我了解了MVVM模式，它承诺在我的WPF应用程序中清晰地分离关注点。

我认为这会很棒！我和我的团队在工作中创建了几个不同的管理和数据输入WPF应用程序，因此我开始使用强大但简单的GUI来制作工作软件，对吧？

没那么快，那里，牛仔编码器。我的经验是写WPF是S-L-O-W。

好吧，至少我这样做的方式。你看，在我在白板上画了我的GUI之后，我用我想要的控件编写了XAML代码。正如预期的那样，这部分很快 - 整个窗口的布局非常快。在那之后，你想要这些元素做的所有小东西需要一段时间。在某些情况下，我似乎总是想要使这个文字变得粗体;在其他情况下显示红色错误框。

然后事情解开了：这个绑定在这里不起作用 - 我必须编写一个转换器并调整正确值的布局。哎呀，我忘记了额外的NotifyPropertyChanged那里。哦，我想在这种状态下使用不同的模板，所以我必须弄清楚在某些情况下我可以使用什么来交换模板。这些数据是异步进入的，所以我需要确保在正确的线程上发生了正确的事情，并且Property也获得了NotifyChanged。废话，当我最大化我的窗口时，它不会像我想象的那样伸展 - 必须是因为它的容器高度没有定义，但我不想定义它，所以我必须让它伸展它的家长。哦，现在我真的想在这里让用户控制这些东西，所以我最好实现一些依赖属性......

我一次又一次地花费数小时和数日来处理那些感觉如此小而小的东西。我很快就会降低可用性和外观增强功能，因为这样做太长了。

为了有效地编写WPF，有没有人需要尝试任何提示或原则？

Answer 1

为我节省了大量时间的一些事情：

• 使用DockPanel作为布局的默认面板，除非您有充分的理由不这样做。
• 保留一个充满有用类的文件夹：一个ViewModelBase类，它实现INotifyPropertyChanged，一个RelayCommand类等等。没有必要去看看并尝试将它作为一个单独的程序集你建立在你的项目中;只需编写相当不错的实现并将它们复制/粘贴到新项目中。
• 获取Resharper并使用它。使用模板创建依赖项属性，更改通知的属性和命令。
• 查找或构建一个用于异步任务管理的良好库。

我发现即使对于非常简单的应用程序，我使用WPF的速度也比使用Windows Forms更快。对于不是很简单的应用程序，绝对没有比较。

在大多数情况下，WPF应用程序需要开发很多工作，因为它很难用于删除UI功能。你不能只是说，“哦，那是不可能的”，因为它可能 可能（无论它是什么）。

Answer 2

我认为正确的答案根本不适用于WPF，但它可以满足您的需求。

大多数时候，当您想要利用新技术时，有时候您的效率和效率都不高，而且您的解决方案并不那么令人印象深刻，创新或者看起来不像其他人。

使用WPF本身可以提高效率。

更多关于项目管理主题而不是编程。完成一些项目后，你的团队和你应该去一些房间讨论：

• 成功案例。
• 开发过程中的问题。
• 利弊。
• 应用程序架构失败。
• 团队和客户内部的沟通问题。
• ......等等。

如果每个人都分享他们的知识，项目经理或团队负责人会很好地记录每个项目的故事，最后每个人都会有“技术诀窍”。

此外，重要的是您不需要为每个新项目重新发明轮子：如果某些模式工作正常，下次也会采用相同的方式，即使这不是最佳方式。如果可能的话，尽量加强它。

设计模式，技术，范例，语言，公司，同事并没有什么是灵丹妙药：微软表示WPF是Windows客户端开发的一个进步，它是：一种更现代的方法来提供灵活的用户界面和一种符合当今所需方法的编程范例，简化了编码人员和设计人员之间的关系，因为WPF拥有XAML，不仅可以分离关注点，还可以按区域分离专业人员（设计师，UI程序员，商业程序员......）

最后，正如我上面所说，WPF不会成为你的灵丹妙药：从自己的成功中学习并阅读很多内容，查看示例应用程序，下载开源解决方案，倾听同事，喝咖啡，毕竟，经过一些令人头疼的事，在不久的将来的某一天，你将利用这些技术（和许多其他技术）。

修改

我想补充一点，使用专有技术的好方法是创建一个Visual Studio指导包，这样您就可以自动执行许多任务，例如创建管理器，视图，模型和其他内容。团队会手工完成。

例如，您可以为类似WPF CRM的应用程序创建指导包，并且可以自动创建模块。当你想要添加一个新模块时，指导包启动一个过程，该过程添加了所有必要的类来开始开发这个新模块，并且它可以创建一个已经与导航管理器，控制器或其他任何东西相关联的样本表单（这只是一个例子）

指导包和T4都是在日常任务中自动执行繁琐或重复任务的好工具：

• http://msdn.microsoft.com/en-us/library/ff631854.aspx
• http://msdn.microsoft.com/en-us/library/bb126445.aspx

Answer 3

编写自己的库，或找到现有的库。

WPF很棒，但开箱即用它会遗漏一些可以加快编码速度的事情。我厌倦了反复写同样的东西，所以我最终创建了自己的库，里面装满了转换器，可视化树助手，附加属性，自定义控件等等，从那时起，我的开发时间大大加快了。 / p>

除了我自己的图书馆，我还开始使用微软的Prism和Galasoft的MVVM Light Toolkit。两者都包含我一直使用的有用对象，并且比我自己编写的代码要好。 （最常用的是来自Prism的NotificationObject，来自MVVM Light Toolkit的RelayCommand，以及来自任何一个的EventAggregator或Messenger，具体取决于项目等。）

我为加快编码时间所做的另一件事是利用Visual Studio的宏。例如，要创建包含更改通知的属性，我编写私有属性，点击生成公共版本的Ctrl+E，Ctrl+R，然后运行一个自动设置PropertyChanged通知的宏在setter方法中。

我几乎从不更改默认宏的setter方法，而是使用PropertyChanged事件来处理应该在setter上发生的任何更改。这不仅可以更容易地跟踪应用程序流，还可以大大减少我用来浪费浏览公共属性以更改setter方法的时间。

Answer 4

自2008年以来，我一直在使用WPF，并且老实说，做得对，干净确实需要花费更多时间，而不是WinForms开发时需要的时间。我写了比Winforms更多的WPF。话虽这么说 - 如果我需要一个简单的内部工具 - 它总是Winforms。如果我有一些面向客户的东西 - 它总是WPF。为什么？ Winforms便宜又脏，你可以免费获得很多。你没有得到的是WPF可以提供的合适和抛光。 WPF的灵活性确实需要付出代价 - 但从长远来看，它对于面向公众的软件来说是值得的。

Answer 5

是WPF是一个障碍，但它也有奖励。您使用MVVM等设计模式走在正确的轨道上。听起来你甚至没有得到依赖属性或事件冒泡的“回报”。但是对UI的控制非常好。几乎所有内容都是内容控件。在表单中，我总是编写自定义控件来获取我想要的UI。在WFP中，我从来没有为UI编写自定义控件，而且我曾经怀疑过。语法是新的，但它很紧凑 - 我在WPF中重写了一个Form应用程序，WPF有1/3行和更多功能。阅读整本关于WPF的书籍只是为了获得基础 - 我喜欢在C＃2010中使用PRO WPF。你也可以说LINQ很复杂，但是男人只需要几次击键即可完成很多工作。 WPF不是您在下次申请时即时获取的东西。