如何加快WPF开发

我所做的是加快日常WPF开发:

1. 忽略你的眼神和感觉。理想情况下,调整对齐和页边距以及定义样式是我做的最后一件事。

2. 使用网格前使用DockPanel,使用StackPanel前使用网格。

3. 当使用网格时,所有东西都是星型大小。稍后我会回来解决这个问题,但是在原型设计期间,对网格实际有多少行和列有一个清晰的概念是非常有用的。

4. 原型在kaxaml中,在表达式混合中完成,在Visual Studio中测试。为这个问题找出一个方法花费了很多时间,而且这仍然是一个正在进行中的工作。但是,Kaxaml非常适合快速查看XAML原型的行为,而Blend非常适合处理视觉效果,并将内容封装到用户控件和样式中。

5. 使用混合时,不要在艺术板中创建布局,而是在对象轮廓中创建布局。当我第一次开发WPF用户界面时,对象的层次结构比它在屏幕上的外观要重要一百倍。我仍在学习如何做到这一点,而且似乎有可能,一旦我足够擅长它,我就不再需要在Kaxaml中进行原型设计了。

6. 做尽可能小的事情。这需要很多纪律。我有一个很好的大型复杂XAML文件,我决定需要编辑控件的模板。首先要做的是创建一个包含该控件的小型XAML文件,然后在其中编辑控件模板。像这样工作的诱惑 就地 很强,因为编辑控件模板只需单击鼠标右键即可。不要这样做。

7. 甚至不要考虑是否应该为我的小型一次性应用程序开发一个视图模型。是的,我应该。

8. 学习混合。真的,真的要学。了解所选对象周围的所有小图标的含义,并注意它们。(这里有一个快捷方式:我没有在那个东西上设置边距,但Blend设置了。这大概是我30%的回答,“混血儿现在在干什么?”问题。)即使我 知道 手工编辑XAML会更快。这又是一个纪律问题,抵制现在就做的诱惑,这样我就可以提高以后做更多事情的能力。

这有点像是说“切片苹果很容易做,但是苹果派味道更好。”我怎么能像切苹果那样容易地做苹果派呢?”好吧,你可以通过使用预先制作好的馅饼皮或购买预先切好的苹果来让事情变得更简单,但这永远也不会那么容易,因为让我们面对现实吧,你正在做一些更复杂、更美味的东西。

这听起来像是风格让你受不了。如果您只是在每个项目中导入相同的样式,那么您可以更快地开始工作。通常我一有我所有的风格就立刻飞行。

否则,使其与拖放WinForms设计器一样简单的唯一方法是使用拖放WPF设计器。

我使用WPF已经有几年了——为了达到最佳速度,我禁用了设计视图,使用片段,集中地进行智能感知(当然还有重新搜索)。

然后我让事情变得简单-我已经描述了几乎所有事情都使用标准布局-即主屏幕位->DockPanel,工具栏停靠在顶部->代码段。

弹出屏幕->DockPanel、工具栏停靠顶部、自定义永久性部分停靠底部(保存和取消按钮)-ViewModel的属性->带有网格、标签和属性的用户控件。

对于样式-首先,当每种类型至少有3个屏幕时,请执行此操作-为每种类型创建资源字典。定义常用样式-标题文本块等。在每个屏幕中导入资源字典并应用样式。

使用非键控样式在app.xaml中应用颜色、边距、填充等。

我想不出更快的方法。至少对我来说,这样做的时候我不需要思考(因此,我可以稍后将我的脑力用于复杂的事情),它提供了一个一致的“LOB外观”,相对容易风格、主题和以后的改变。基本上是打字的问题。

目前我面临的最大挑战是,我一直在思考如何使用数据模板动态地组合UI,当不需要额外的灵活性时,这些模板通常会妨碍更简单的解决方案。除此之外,我已经变得更快了,因为我已经习惯了不同的容器和它们的怪癖。这是一种非常不同的技术,在我为日常的用户界面任务开发合适的心理工具集之前需要花费时间,特别是因为我仍然需要定期使用winforms。不过,我认为,在我想到可以快速轻松地部署的标准模式之前,这只是时间问题。

关于VS2010的建议非常好;与VS2008的XAML设计器相比,它的可视化设计器实际上很有用,后者也不那么无用。

微软的公关机器为业务线应用程序广泛推出了“模型-视图-模型”模式,以至于他们实际上会推荐一些可以浪费你时间的东西。

做 不 花几个小时的时间尝试将Horn的所有内容放入XAML,除非您的公司或客户有需要它的程序。如果您可以在VB或C中更快地对其进行编码,并且代码仍然是可维护的、可测试的和可读的,那么就这样做。

做 不 成为一个MVVM纯粹主义者;即使是微软也没有为这个模式找到合适的平衡,即使是使用Silverlight4,他们也没有为这个模式找到一套好的开发工具或最佳实践,尽管它从最初被提出到现在已经将近五年了;仍然有非常合理的理由放弃它。n ICommand和InotifyPropertyChanged支持从后面的代码中对ViewModel调用方法。而且,在过去的几个月里,我听过的非微软WPF/Silverlight专家中没有一个没有说“我对MVVM还不确定,我不是一个纯粹主义者”。

找到一个平衡点,并使用XAML来计算什么对你有用,使用C或VB来计算什么对你有用。在他们的博客中,开发人员喜欢将XAML称为“标记”,而C或VB则是“不幸的是,代码”。好吧,如果你在输入或布局它,它都是代码,事实是所有的XAML都被解释,然后在编译之前,在你看不到或不容易编辑的文件中变成C或VB。(例如,application.g.vb是作为分部类从application.xaml生成的。)

有些XAML结构(如动画和故事板)需要在XAML中布置许多行,但在过程语言中,可能只需要一行或两行代码,而且实际上更容易阅读,特别是当动画仅在特定条件下响应事件时。做最有效的事。

另外,如果您正在编码,并且不断地遇到一些毫无意义的运行时异常,请后退一步,找到一个能让您正常工作的替代答案,并实现它。IntelliSense或编译器无法捕获大多数XAML错误。对于一个XAML问题,可以用C或VB进行编码,并在相对较短的时间内进行早期绑定,这是可能的。

简言之,使用VS2010工具,放松并编写您自己的最佳实践代码,您应该能够加快速度。

如果您使用VS2010,我认为XAML的可视化设计器现在更好了,我认为开发时间更符合经典的WinForms开发。

如果仍然需要以.NET 3.5为目标,可以将解决方案设置为编译为3.5而不是4.0。如果您还没有使用VS2010,这可能是一个很好的选择。

我感觉到你的痛苦…每次我们向数据库中添加新字段时,都必须在表单上创建另一个文本框/组合框。我发现使用ExpressionBlend可以让我更快地布局表单。缺点是使用混合比手工编写更容易创建更多的XAML,所以我通常会稍微清理一下XAML。

最后,Blend是一个比Visual Studio(包括2010)好得多的设计师,所以在Blend中进行设计工作和在VS中进行开发工作要快得多(仅我的两分钱)。