仅包含代码的 WPF答案

【问题标题】：WPF with code only仅包含代码的 WPF
【发布时间】：2011-02-20 03:03:16
【问题描述】：

我在这里看到了很多关于 WPF 优点的问题，基本上每个答案都说这是蜜蜂的膝盖，但基本上每个答案也谈到了诸如 XAML 之类的东西，在许多情况下是图形设计师和 Expression Blend 等。我的问题是，如果你是一个只在 C# 中工作的独立程序员，是否值得进入 WPF？

具体来说，我自己既没有平面设计师，也没有这方面的天才；我不使用点击工具；我用 C# 编写所有内容，而不是 XML。

Winforms 在这些条件下运行良好。 WPF 也是如此，还是事实证明重要功能只能在 XAML 中完成，默认设置不适合实际使用，并且您必须在团队中有图形设计师才能使事情看起来不错，等等.，而像我这样的人最好还是坚持使用 Winforms？

【问题讨论】：

是我弄错了，还是你真的为拒绝使用合适的工具而自豪？
我不认为 proud 或 proper 是正确的词。我认为这是一个偏好问题。我发现拖放工具总是让我头疼，所以我拒绝使用它们。如果必须，我将手动编辑 XML，但如果可能的话，我更喜欢纯粹在 C# 中工作。我想知道 WPF 如何适应这些偏好。
WPF 将适应您的偏好，但我们强烈建议您学习 WPF 的处理方式。拥有具有良好预览功能的体面的 WPF 设计器可以显着缩短“修改 -> 预览 -> 修改”周期。如果“修补”用户界面不那么痛苦，您可能会喜欢花时间在上面，并且可能会设计出更好的设计。

标签： c# .net wpf winforms

【解决方案1】：

我自己就是一个代码人，老实说，这没关系。即使你对平面设计一无所知，你仍然可以使用 Visual Studio 中的编辑器来设计 UI。设计器具有与 Win Forms 一样的拖放设计器，因此这并没有真正造成问题。即使我是一个代码人，我对 xaml 没有任何问题，因为它在某种程度上再次编码。一开始我也遇到了 xaml 的问题，但我已经习惯了，我必须在 Win Forms 中的代码中做的事情在 xaml 中很容易。

数据绑定很简单，您不必关心将数据发送到 UI，您只需拥有一个 ObservableCollection<T> 或类似名称，以及 xaml 代码中的一个属性，一切都会为您完成。想要格式化数据？只需将格式属性添加到绑定。想要根据值对文本着色？ Template Selector 类有 15 行代码，Binding 和 Template selection 在 xaml 代码中大约 10 行。我真的越来越喜欢它了，随着时间的推移（就像任何其他新技术一样）你会习惯它，并生产出好看的东西。

【讨论】：

【解决方案2】：

简答：是的，你可以只用代码来做 WPF。

更长的答案：关于设计师能够在 UI 上工作和开发人员能够在功能上工作的部分实际上只是将功能与演示分离的副作用。

WPF 的强大之处在于数据绑定，它使您能够使用更广泛的设计模式。 MVVM 已经讨论了很多 recently。

各种MVVM framework 鼓励约定优于配置，允许您编写更少的代码来实现相同的目标。
这种解耦还有一个很好的副作用，那就是使您的应用程序更易于测试（如果您不想编写测试，则不必编写测试，但至少可以选择）。

从 WinForms 迁移到 WPF 对于您的新开发来说很可能是值得的。理论上，您可以继续使用 WinForms（只是使用新库）继续做您一直在做的事情，但是随着您对技术的熟悉程度越来越高，您可以选择将更新的工具整合到您的开发中。

如果您还没有看过，Scott Hanselman 的 BabySmash series 非常有趣。

【讨论】：

【解决方案3】：

恕我直言，只要确保您掌握这些技能，就值得走 WPF 路线。我玩过基于 XAML 的 Silverlight，即使 SL 是一个子集，我也可以将大部分知识转移到 WPF。

老实说，一旦您习惯了它，大多数 UI 的构建与使用 WPF 和使用 WinForms 一样容易。而且工具非常好，使用SketchFlow 进行原型设计很有用，并且不需要你具备任何真正的艺术技能，除了你有做WinForms 的东西。我相信今后，更多地了解 WPF 只会让我受益，而且我相信其他人也会如此。

【讨论】：

正如您所说，拥有设计有吸引力的界面的技能肯定是有价值的。另一方面，如果一个人更喜欢用 C# 而不是 XML 构建所述接口，WPF 会适应吗？
@rwallace，我指的不是设计有吸引力的界面的技能，而是对WPF的知识和理解，这就是我指的技能。您绝对可以在代码中构建 UI，您可以坚持使用 IDE 中的设计器，或者您可以手动编写 XAML 代码，甚至可以混合使用以上所有内容。

【解决方案4】：

所有可以在 XAML 中完成的事情也可以在代码中完成，因为 XAML 只是一个用于实例化和配置对象图的 DSL - 特别是 WPF 库中的那些 (System.Windows)。如果您正在构建业务线应用程序，那么 WPF 提供的几乎所有功能在 WinForms 中根本不可用。主要区别在于 WPF 允许您更轻松、更灵活地做很多事情，因为它具有更高级的对象模型。

我认为WPF当然值得学习，但如果你想在不学习XAML的情况下做到这一点，那么我想你可能会发现它更难学习。

还值得考虑的是，许多 WPF 开发人员手工编写 XAML（而他们的设计师同行将更有可能在第一个实例中使用 Blend）部分是出于必要（Visual Studio 2010 之前的 WPF 设计器不是很好)，部分原因是对象模型在 XAML 中比在 C# 中更简洁。 XAML 本身是一种非常小的语言，但它用于定义的对象模型（WPF 对象模型）非常庞大——这就是复杂性的来源。

如果您没有令人信服的理由停止使用 WinForms，那么不要这样做。但是，如果您能够抛开关于用 XML 而不是 C# 编写代码的先入之见，那么我想您可能会惊讶于这种构建 UI 的不同方法会如何清理您的代码。

【讨论】：

【解决方案5】：

我说 WPF 可以适合你，如果你不想采用 xaml 方式并且只编写代码，你应该继续这样做，在 xaml 中某些事情是不可能的，但它是进行布局的首选方式，但是没有人强迫你不要在代码中做，但是如果你学习 xaml，你会更快地生成 UI 元素，然后你会在代码中，所以要记住这一点。

【讨论】：

谢谢，这听起来很有希望。我会问，XAML 如何让你比代码更快地生成东西？我在其他框架中尝试过类似的技术，并没有发现它们可以提高我的工作效率，但也许 WPF 不一样？
XAML 是标记，因此您可以描述一个绝对的星座，而不用担心正确的“时间”、事件链和以正确的顺序做事。这有助于让简单的事情变得简单。核心计算等将始终保留在您的代码中，就像以前一样。

【解决方案6】：

这是一篇旧帖子，但是... 在我看来，当您在任何环境中自己编写代码时都没有界限，并且总是需要发现一些东西。过去很多年人们一直在代码中创建布局，但某些因素促使社区创建图形和 ui 工具。但同样，没有什么是永恒的，趋势变化很快。还记得从 ASP 内联编码到 ASP.NET 的布局组合样式，然后再回到 ASP.NET MVC 的内联。是不是退了一步？当然不是，因为它受到其他技术和工具的支持，如剃刀、动态语言、模型绑定器等。所以，实际上没有人能告诉你正确的工作方式，只要你遵循基本规则和标准，并意识到它不仅仅是代码，而是今天的代码，包括所有的 lambda、linq、表达式、匿名、DLR 等。谁知道？也许您将成为创造一种表达和推动内容的新方式的人。

【讨论】：