我不喜欢使用 XAML。我更喜欢用 C# 编写所有代码，但我认为我做错了。
在哪些情况下使用 XAML 更好，什么时候使用 C#？你的经验是什么？
【问题讨论】：
标签： c# wpf xaml code-behind
我最初来自 Web 方面的开发，目前正在学习 WPF/Silverlight。对我来说，XAML 模型对我来说比 WinForms 更有意义。我将 XAML 视为 HTML，将 .cs 文件视为代码隐藏。
【讨论】：
在 C# 中创建整个窗口可能是一堆乱七八糟的代码。 WPF 的最大优点是 XAML 允许您将设计与逻辑分开，从而使代码更易于阅读。
当我需要创建动态控件时，我会使用 C#，但我倾向于将我的一般设计、静态故事板、样式、数据模板等保留在 XAML 中。
【讨论】：
我的经验是，在 C# 中执行某些操作要快得多，而在 XAML 中执行大多数操作要快得多。当需要 5 行 C# 代码来完成单行 XAML 代码可以做的事情时，我很容易选择哪个更好。
【讨论】：
有些东西在代码中更容易维护或调试。
【讨论】：
查看 WPF 中 MVVM 上的 this video。如果您想了解如何组织 WPF 应用程序与 XAML 中的内容、代码隐藏和其他抽象，这是一个很好的起点。
【讨论】：
想要用 C# 而不是 XAML 编写 UI 的冲动实际上只是表明您对 XAML 的适应程度。
对我来说，编写尽可能少的代码隐藏是个人目标。简而言之，后面的代码很难进行单元测试，但可以（并且通常会）包含未经测试的逻辑。 XAML 是声明性的（如 HTML），不包含任何逻辑，因此无需进行单元测试。我将视图代码保存在 XAML 中，并将视图逻辑保存在非常容易测试的 ViewModel (MVVM) 中。
一旦您对 XAML 更加熟悉，您就会越多地意识到它相对于过程代码中的视图构造的优势...使用像 MVVM 这样的模式，您会更进一步，并意识到代码隐藏仅在罕见的情况。
【讨论】：
这不仅仅关乎你，还关乎你的团队，其中一些人可能是设计师。
【讨论】：
更不用说您将能够在 Xaml2009 中做更多现在必须在代码中完成的事情。
不幸的是，BAML 在 2010 年的时间范围内不会完全支持 xaml 2009，因此您无法在 2010 年的时间范围内编译 xaml。并且将不得不等待更高版本的混合来完成完整的开发设计循环。 （迟于3）
道格拉斯
【讨论】：
要记住的最重要的事情是 XAML 用于演示。您的所有演示文稿都应该在 XAML 中。如果您有逻辑，则将其保留在您的 XAML 之外 - 在您的 C# 中。
想象一下，将您的 XAML 文件换成一个看起来完全不同的文件 - 但仍然使用相同的数据 - 这就是划分的地方。
【讨论】：
您当然可以在使用 XAML 时走得太远。那些希望在 XAML 中定义其整个用户界面（包括逻辑、事件处理关系等）的人可能没有抓住重点。
XAML 的目的是提供一种通用格式来确定事物的外观。它应该只是描述如何布置、如何在视觉上为它们着色和样式。
尝试用它来替代 C# 的其他方面确实没有什么意义，因为 C# 在编程特性方面具有永久的领先优势 - 重用（定义类型和函数）、引用变量、过程编程，甚至是声明式或函数式样式。
我个人非常喜欢将 UI 与 Linq 表达式组合在一起！
我看到的一个示例达到了最大的荒谬之处，他们使用工作流操作作为按钮的子级来提供Click 处理程序，因此整个程序都在 XAML 中。这听起来很“酷”，但问题是它比等效的 C# 或 VB.NET 程序更丑陋和不可读，因此准备在 C# 中使用的所有内容都必须替换为更冗长、片状的等效程序。翻译成更丑陋的语法实际上并没有带来任何好处——它只是更丑陋的同一个程序。 XML 对于通用编程语言的语法来说是一个很差的基础。首先是大于号必须写成>!
在平行宇宙中，微软在完成 XAML 之前发布了 C# 3.0。 XAML 团队采用 C# 3.0 对象/列表初始值设定项语法而不是 XML 作为他们的语法。而这整个辩论从未发生过。
【讨论】：
基本上，XAML 用于表达视觉设计，C# 用于表达逻辑。
任何视觉设计都应该在 XAML 中完成，任何逻辑都应该在 C# 中实现。
- 这可以让设计人员继续进行视觉设计，而不必担心逻辑的更改，甚至可以在运行时使用松散的 XAML 替换整个视觉设计。
- 这也意味着您可以在不“破坏”的情况下替换逻辑或视觉设计。
- 两者之间的连接应该通过数据绑定和命令绑定来完成。
我使用的做法是：
1. 在单独的 C# 代码中定义模型（业务数据对象模型）。
2.定义视图的常量部分（图形用户的常量部分
接口，例如XAML 中的窗口、菜单...）（最好使用 Blend 而不是 VS）。
* 不要在此处定义样式（颜色、字体等）。
* 不要在 XAML 代码隐藏中为按钮（大多数情况下）编写事件处理程序，而是使用命令绑定。
3. 使用位于单独文件中的 XAML“ResourceDictionary”定义模型在视图（用于查看/编辑数据对象的 GUI）中的呈现方式。
- 使用 blend 编写，然后使用 VS 将绑定添加到 XAML（Jetbrains 的 VS 的 Resharper 插件将有助于绑定表达式）。
- 如果在设计时不知道对象类型，您可以使用“loose-XAML”并将 XAML 放在一个文件夹中，该文件夹可以在其中添加/编辑文件而无需重新编译。
4. 在 C# 中创建模型和视图（控制器/视图模型）之间的连接：
* 根据需要创建视图（用于动态对象）
* 将视图数据绑定到模型（将视图的 DataSource 设置为模型内的相关对象）
* 实现命令
* 命令将视图绑定到自身内部的命令实现
5. 在 Application.xaml 中删除 StartupUri="MainWindow.xaml" 并添加 Startup="ApplicaitonStartUp"。
在 ApplicationStartUp() 事件处理程序中：
* 加载您拥有的任何松散 XAML
* 创建控制器
* 创建主窗口
* 创建模型
* 将控制器连接到模型和主窗口
* 显示主窗口
*（将模型、控制器和主窗口保存到此处的私有字段中，以确保它们都保持活动状态）
6. 将样式（颜色、字体）添加到 ResourceDictionary 下的单独 XAML 文件（为此使用 blend 或购买现成的 XAML 主题/皮肤文件）。
【讨论】：
我喜欢干净的代码，我拥有的代码越少，它就越干净。代码可以用数百万种方式编写，XAML 更具限制性。 XAML 擅长在适当的时候减少代码。如果我可以在 XAML 中添加一些东西，我会这样做。工具可以读取 XAML 并用它做一些事情。代码少得多。处理 XAML 的工具和框架将发展并变得更好，与现有 XAML 一起做更多更好的工作。不能这么说代码。 XAML 发展得越多，我们就越能够以声明方式定义我们的应用程序。
对我来说，使用 XAML 就像使用 LINQ。如果我可以写一个易于阅读的单行语句并让框架决定实现我想要的最佳方式，我感觉很好。我肯定会尽我所能地尝试使用我想要的声明，而不是硬编码我希望它如何完成。 F# 是这种范式的另一个很好的例子。
【讨论】：
XAML 的优点之一是表示与逻辑的分离。这种分离不仅是理论上的，也是实际的。我的情况是，我的大部分用户界面现在都由设计师处理。这位设计师使用blend，不懂C#，对学习c#没有兴趣，坦白说应该不需要。这位设计师是一位真正的设计师，一位艺术家，他知道如何使用这些工具让事物看起来非常非常漂亮。 基本上我的原理是这样的，我使用 XAML 的次数越多，我在 UI 上要做的工作就越少，因为他可以做到。这对我们来说效果很好。我通常将我的控件设计为不显眼，给它们一个基本的简洁外观，使用 DataContext 绑定我的对象（顺便说一句，DataTriggers 是减少代码的好方法）。结果，我会经常检查我的代码，第二天回来，同步它，UI看起来会完全不同，但一切仍然有效！！！
当然，至少花了 1/2 年才到那里，但现在这个模型似乎工作了，我们的 UI 看起来 Kick A##，我们的应用程序获得了很高的评价，我在 UI 本身上做的很少，得到从事更酷的事情。长话短说，我认为背后的代码可能更加以开发人员为中心，而忽略了其他可以使用 WPF 受益、努力和谋生的群体，即设计师。
当然，有时仍然需要开发人员来让 XAML/WPF 唱歌跳舞，有时我们需要教育设计人员正确的做事方式，但我认为投资是值得的在大型项目中多次出现（也许短期内不会如此0
【讨论】：
XAML 可以看作类似于用于结构和设计的 XHTML 和 CSS 或 XML 和 XSL 的组合。任何形式的逻辑都应该在 C# 中。 这种方式结构和设计与逻辑分离。使用这种方法，您的代码也应该更干净。另一个积极的事情是，任务可以更容易地在设计师和程序员之间分离。
还有一件事……这是 MSDN 对 XAML 的定义：
可扩展应用程序标记语言 (XAML) 是一种用于声明式应用程序编程的标记语言。 Windows Presentation Foundation (WPF) 实现了可扩展应用程序标记语言 (XAML) 加载程序，并为 Windows Presentation Foundation (WPF) 类型提供可扩展应用程序标记语言 (XAML) 语言支持，以便您可以在可扩展应用程序标记中创建应用程序 UI 的大部分语言 (XAML) 标记。此外，SDK 还包括一个名为 XAMLPad 的可扩展应用程序标记语言 (XAML) 编辑工具。您可以使用此工具实时试验可扩展应用程序标记语言 (XAML)。
【讨论】：
如前所述，XAML 和 C# 是一种将逻辑与设计分开的非常好的方法。
对于一个典型的程序员来说，使用 WPF 确实改变了编程的方式，假设程序员来自 C++、VB、WinForms、ATL 和 MFC 背景，那么 UI 与逻辑并没有那么自然分离与 XAML 和 C# 一样。
要习惯这种编程方式需要一些时间，但随着经验的积累，它会变得非常有效。
在开始之前，学习 MVVM 模式并运行教程以了解该模式的优势并了解其好处是非常好的。
基于 MVVM 模式的 WPF 和 C# 应用程序的好处：
1.用户体验和可用性 将逻辑与 UI 分离，让专门的设计师负责 UI 设计和动画变得更加自然。这样，程序员可以专注于背后的逻辑和技术解决方案，而 UI 是由懂设计的人设计的。 这对许多软件公司来说都是一个问题，至少在业内，程序员实际上也是曾经设计 UI 的人，这导致了大量的支持、维护和有效的应用程序。
如果有一个具有可用性背景的人专注于使用而不是技术解决方案，那么它最终会产生更用户友好的应用程序的可能性更高。 Joel Spolsky 所著的《程序员用户界面设计》是一本关于此类示例的非常有趣的书。
通过对 XAML 应用程序使用 MVVM 模式，我们很有可能会看到更多用户友好的应用程序。
2。维护 维护，在软件开发中成本很高。 一开始可以感觉到 MVVM 模式是一个很大的开销，但是随着功能的增加，应用程序越复杂和高级，它的好处就越大。您将看到维护这样的应用程序非常容易。 有关概述，您可以查看此视频：
3.综合能力 专门的设计师和专门的程序员在团队中工作以获得更好的结果是混合能力的一种非常好的方式。组织需要结合能力以提供最佳结果，而不是只雇用程序员。
4.对设计感兴趣的程序员的机会 最后，可以在 Windows 环境中实现精美的应用程序。如果您是一名对设计感兴趣的程序员，Microsoft Expression Blend 确实为您提供了学习和实现具有精美设计的精美实用应用程序的可能性。
尽管使用 XAML 和 C#、MVVM 可能存在风险，但它提供的巨大可能性和灵活性也可能是一个缺点。让程序员在这个新的简单 UI 环境中放松，应用程序最终可能会得到广泛的动画、颜色，以及这个新环境提供的一切。记住您是如何在 C++ 和 ATL 环境中添加 UI 控件的。
仍然有更多的好处，我希望你能获得一些灵感，使用 XAML 而不是 C# 作为 UI，当习惯它时，我相信你会喜欢它。
一个好的教程的链接： Tutorial MVVM XAML C#
【讨论】：
XAML、MXML 所有这些东西只要你正在开发一个简单的 UI 并且具有一定的平均复杂性就可以工作。一旦你的 UI 变得复杂和丰富，自动数据绑定会带来更多的麻烦而不是好处。 XAML 的目的不是让编程变得简单，而是将 UI 与逻辑分开，以便 UI 的工具化..
没有数据绑定，没有事件处理程序..假设您再也不会看到您的 XAML 并编写代码..
XAML 是演示文稿。数据绑定不是表示。它的表示逻辑。将所有表示逻辑放在代码后面（数据绑定和处理程序）。开发人员拥有背后的代码，设计人员拥有 XAML。如果您是开发人员并且您正在接触 XAML，那么将该部分移到代码后面。
我们也可以在没有 XAML 的情况下编写 WPF 应用程序 ..
谢谢 维诺特·库马尔 R （已经足够使用 Flex MXML 数据绑定了）
【讨论】：
无论您在计算机编程中使用什么编程语言，所有逻辑都应该在代码中。即使在 ControlTemplate 中，XAML 也不应该取代它，尽管它很好，但单元测试和调试代码要容易得多。
【讨论】：
使用流利的风格在 C# 中编程 WPF 有助于降低代码大小和复杂性。有关在 WPF 中使用流畅样式的示例，请参阅 this answer。
【讨论】：
似乎还没有答案提到重要的一点： https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh465340.aspx
XAML 只是程序代码（只是更简单）
<Grid x:Name="ContentPanel" Margin="12,0,12,0">
<Button Height="72" Width="160" Content="Click Me" />
</Grid>
“下面展示了如何用 C# 或 Visual Basic 编写的代码部分替换此 XAML。”
// Initialize the button
Button myButton = new Button();
// Set its properties
myButton.Width = 160;
myButton.Height = 72;
myButton.Content = "Click Me";
// Attach it to the visual tree, specifically as a child of
// a Grid object (named 'ContentPanel') that already exists. In other words, position
// the button in the UI.
ContentPanel.Children.Add(myButton);
例如，如果您使用过 Windows 窗体，您可能还记得 Windows 窗体设计器会生成一个 .designer.cs 文件，其中包含与上面链接中的示例类似的代码。这种声明性代码在 XAML 中比 C# 更好地表示。
对于任何非玩具应用程序，您应该始终更喜欢 XAML 来定义 UI 并以 MVVM 方式将其连接到逻辑。
【讨论】：
ContentPanel.Children.Add(new Button { Width = 160, Height = 72, Content = "Click Me });。这是我个人认为比所有尖括号更容易阅读的一行。我不是在权衡“使用或不使用 XAML”的问题——我只是不喜欢不公平的示例比较。
我认为这主要是偏好。我使用 WPF，因为它更容易构建不同的屏幕并将 C# 代码逻辑与 UI 分开。通常，我的所有逻辑都是在另一个 C# 库中构建的，而不是我的 UI，它是 WPF 或 Windows 窗体中的启动项目
【讨论】：