我用WPF开发了好几个月了。这是一个很棒的框架，我可以做一些花哨，优雅的东西，使用WinForms会更加困难。
但是，我确实感觉对于没有任何特殊UI要求的正常“业务线”类型的应用程序，在XAML中编写UI所需的时间比在WinForms中拖放它所花费的时间更长。
例如，在WinForms中，我只需在表单上删除一个额外的标签和一个额外的文本框，并安排所有内容（使用帮助行），直到它看起来不错。在WPF中，我首先将现有标签和文本框的属性分解为样式，因此我可以重用它们;想想最合适的布局元素，可能会将一些dockpanels / stackpanels重构成一个网格（反之亦然）;尝试不同的边距值等。尽管我在WPF方面有很多经验，但仍需要很长时间。
我知道我可以忘记“干净的XAML”并使用Visual Studio 2008中的GUI设计器（它绝对将所有内容放在一个巨大的网格中），但我担心我会失去很多XAML的优点通过这样做提供。
您是否经历过类似的事情？如果是，你做了什么来加速日常WPF开发？
答案 0 :(得分：5)
我如何加快日常WPF开发：
尽可能地忽略外观和感觉。理想情况下，调整路线和边距以及定义样式是我做的最后一件事。
在使用网格之前使用DockPanel，在使用StackPanel之前使用网格。
使用网格时，星标大小。我稍后会再回过头来解决这个问题，但在原型设计过程中，明确了解Grid实际拥有的行数和列数是非常有帮助的。
Kaxaml中的原型，在Expression Blend中完成，在Visual Studio中进行测试。找出一种方法可以花费很多时间，而且它仍然是一项正在进行中的工作。但是Kaxaml非常适合快速查看XAML原型的行为，而Blend非常适合处理视觉效果并将内容封装到用户控件和样式中。
使用Blend时，请勿在画板中创建布局，请在对象轮廓中创建布局。当我第一次开发WPF UI时，对象的层次结构比它在屏幕上看起来的重要性高出一百倍。我还在学习如何做到这一点，似乎有可能一旦我对它变得足够好，我将不再需要在Kaxaml中进行原型设计。
尽可能做最小的事情。这需要很多纪律。我有一个很好的大复杂XAML文件，我决定我需要编辑控件的模板首先要做的是创建一个带有该控件的微小XAML文件，并在那里编辑控件模板。像 in situ 这样工作的诱惑力很强，因为编辑控件模板只需单击鼠标右键即可。不要这样做。
甚至不考虑我是否应该为我的小型一次性应用程序开发一个视图模型。是的，我应该。
学习混合。真的，真的学习它。了解所选对象周围的所有小图标是什么意思，并注意它们。 （这是一个捷径：我没有在那个东西上设置边距，但Blend做了。这可能是30％我的“Blend现在在做什么？”问题的答案。）即使我
答案 1 :(得分：3)
这有点像说“切苹果很容易制作，但苹果派的味道更好。我怎样才能像切苹果一样轻松制作苹果派？”好吧，你可以通过使用预先制作的馅饼皮或购买预先切好的苹果来简化它，但它永远不会那么简单，因为让我们面对它，你正在做一些更复杂和可能更美味的东西。 / p>
听起来好像制作风格会让你感到高兴。如果您只是为每个项目导入相同的样式，那么您可以更快地开始。通常，一旦我制作了所有款式，我就会一直飞行。
否则，让它像拖放WinForms设计器一样简单的唯一方法就是使用拖放式WPF设计器。
答案 2 :(得分：2)
我已经使用WPF几年了 - 为了获得最佳速度，我禁用了设计视图，使用了片段，智能感知（当然还有ReSharper）。
然后我简单地说 - 我已经决定使用几乎所有东西的标准布局 - 即。主屏位 - ＆gt; DockPanel，ToolBar停靠顶部 - ＆gt;片段。
弹出屏幕 - ＆gt; DockPanel，ToolBar停靠顶部，自定义持久部分停靠底部（保存和取消按钮） - viewmodel的属性 - ＆gt; UserControl包含网格，标签和属性。
对于样式 - 首先，当每种类型至少有3个屏幕时 - 为每种类型创建资源字典。定义常用样式 - 标题文本块等。在每个屏幕中导入ResourceDictionary并应用样式。
在App.Xaml中使用非键控样式应用着色，边距，填充等。
我想不出更快的方法。至少对我来说，这样做时我并不需要思考（因此，我可以在以后使用我的脑力来处理复杂的东西） - 并且它提供了一个相对容易风格的一致的“LOB外观”，主题和以后的变化。这基本上是打字的问题。
答案 3 :(得分：1)
我目前面临的最大挑战是，我一直在思考如何使用数据模板动态组合UI，这在不需要额外灵活性的情况下通常会妨碍更简单的解决方案。除此之外，我已经变得更快，因为我已经习惯了不同的容器和他们的怪癖。这是一个非常不同的技术，在为我的日常UI任务开发适当的心理工具集之前需要花费时间，特别是因为我仍然需要定期使用WinForms。我认为这只是一个时间问题，然而，在我有标准模式之前，我可以快速轻松地部署。
答案 4 :(得分：1)
关于VS2010的建议非常好;与VS2008的XAML设计师相比，它的视觉设计师实际上是有用的，而且不是没用。
微软的PR机器广泛推出了针对业务线应用程序的“Model-View-ViewModel”模式，以至于他们实际上推荐了可能浪费你时间的东西。
除非您的公司或客户有需要的程序，否则不花费数小时试图将所有内容都用于XAML。如果你可以在VB或C＃中更快地编写代码，并且代码仍然可维护，可测试和可读，那就去做吧。
不成为MVVM纯粹主义者;微软甚至没有为这种模式找到适当的平衡，即使使用Silverlight 4，他们也没有为该模式提供一套好的开发工具或最佳实践，尽管现在已经差不多五年了。它是最初提出的;放弃ICommand和INotifyPropertyChanged仍然有很好的理由支持从代码隐藏中调用ViewModel上的方法。此外，在过去的几个月里，我听过的非Microsoft WPF / Silverlight专家都没有说“我还不确定MVVM，我不是纯粹主义者。”
找到一个平衡点并使用XAML来解决对你有用的问题，并使用C＃或VB来解决对你有用的问题。 MS devs在他们的博客上喜欢称XAML为“标记”，而C＃或VB则是“代码，不幸的是”。好吧，如果您正在输入或者将其打包出来，那就是所有代码，事实是所有XAML都被解释，然后在编译之前转换为C＃或VB，这些文件是您无法看到或不易编辑的文件。 （例如，Application.g.vb是从Application.xaml生成的一个部分类。）
有一些XAML构造，如动画和故事板，在XAML中需要很多行，但在过程语言中可能只需要一行或两行代码，实际上更容易阅读，特别是如果动画响应事件只在某些条件下。做最好的事情。
此外，如果您正在进行编码并继续点击无意义的运行时异常，请退后一步，找到让您运行的备用答案，并实施它。 Intellisense或编译器无法捕获大多数XAML错误。对于XAML问题可能会持续数周，可以用C＃或VB编码，并在相对短的时间内进行早期绑定。
简而言之，使用VS2010工具放松并编写自己的最佳实践代码，您应该能够加快速度。
答案 5 :(得分：0)
如果您使用VS2010，我认为XAML的视觉设计师现在更好，我认为开发时间更符合经典的winforms开发。
如果您仍需要以.NET 3.5为目标，则可以将解决方案设置为3.5而不是4.0。如果您还没有使用VS2010，这可能是一个不错的选择。
答案 6 :(得分：0)
我感觉到你的痛苦...每次我们在数据库中添加一个新字段时，必须在表单上创建另一个TextBox / ComboBox。我发现使用Expression Blend可以让我更快地布局表单。缺点是使用Blend会产生比手工编写更多的xaml，所以我通常最终会清理xaml。
最后，Blend是一个比Visual Studio（包括2010年）更好的设计师，因此在Blend中进行设计工作和在VS中进行开发工作要快得多。 （只是我的两分钱）