我不喜欢使用 XAML。我更喜欢用 C# 编写所有内容,但我认为我做错了。
在哪些情况下使用 XAML 更好,什么时候使用 C#?你的经验是什么?
在 C# 中创建整个窗口可能是一堆乱七八糟的代码。WPF 的最佳之处在于 XAML 允许您将设计与逻辑分开,从而使代码更易于阅读。
当我需要创建动态控件时,我将使用 C#,但我倾向于将我的一般设计、静态故事板、样式、数据模板等保留在 XAML 中。
在 WPF 中查看有关 MVVM 的视频。如果您想了解如何组织 WPF 应用程序与 XAML 中的内容、代码隐藏和其他抽象相比,这是一个很好的起点。
您当然可以使用 XAML 走得太远。那些希望在 XAML 中定义其整个用户界面(包括逻辑、事件处理关系等)的人可能没有抓住重点。
XAML 的目的是提供一种通用格式来确定事物的外观。它应该只是描述如何布置东西,如何在视觉上给它们上色和样式。
试图用它来替代 C# 的其他方面确实没有什么意义,因为 C# 在编程特性方面具有永久的领先优势 - 重用(定义类型和函数)、引用变量、过程编程和甚至声明式或函数式样式。
就我个人而言,我真的很喜欢将 UI 与 Linq 表达式组合在一起!
我看到的一个示例达到了最终的荒谬性,他们使用工作流操作作为按钮的子级来提供Click
处理程序,因此整个程序都在 XAML 中。这听起来很“酷”,但问题是它比等效的 C# 或 VB.NET 程序更丑陋和不可读,因此准备在 C# 中使用的所有内容都必须替换为更冗长、片状的等效程序。翻译成更丑陋的语法实际上并没有带来任何好处——它只是更丑陋的同一个程序。XML 对于通用编程语言的语法来说是一个很差的基础。从大于符号必须写成的事实开始>
!
在平行宇宙中,微软在完成 XAML 之前发布了 C# 3.0。XAML 团队采用 C# 3.0 对象/列表初始值设定项语法而不是 XML 作为他们的语法。而这整个辩论从未发生过。
我的经验是,有些事情在 C# 中执行起来要快得多,而大多数事情在 XAML 中执行得更快。当需要 5 行 C# 代码来完成单行 XAML 代码可以做的事情时,我很容易选择哪个更好。
基本上,XAML 用于表达视觉设计,C# 用于表达逻辑。
任何视觉设计都应该在 XAML 中完成,任何逻辑都应该在 C# 中实现。
- 这使得视觉设计可以让设计师继续使用,而不必担心逻辑的变化,甚至可以在运行时使用松散的 XAML 替换整个视觉设计。
- 这也意味着您可以在不“破坏”的情况下替换逻辑或视觉设计。
- 两者之间的连接应该通过数据绑定和命令绑定来完成。
我使用的做法是:
1. 在单独的 C# 代码中定义模型(业务数据对象模型)。
2. 在 XAML 中定义视图的常量部分(图形用户界面的常量部分,例如窗口、菜单等)(最好使用 Blend 而不是 VS)。
* 不要在这里定义样式(颜色、字体、...)。
* 不要在 XAML 代码隐藏中为按钮(在大多数情况下)编写事件处理程序,而是使用命令绑定。
3. 使用位于单独文件中的 XAML“ResourceDictionary”定义模型在视图(用于查看/编辑数据对象的 GUI)中的呈现方式。
- 使用 blend 编写,然后使用 VS 将绑定添加到 XAML(Jetbrains 的 Resharper VS 插件将有助于绑定表达式)。
- 如果在设计时不知道对象类型,您可以使用“loose-XAML”并将 XAML 放在一个文件夹中,该文件夹可以在其中添加/编辑文件而无需重新编译。
4. 在 C# 中创建模型和视图(控制器/视图模型)之间的连接:
* 根据需要创建视图(用于动态对象)
* 将视图绑定到模型(将视图的 DataSource 设置为模型中的相关对象)
* 实现命令
* 命令将视图绑定到自身内部的命令实现
5. 在Application.xaml 删除 StartupUri="MainWindow.xaml" 并添加 Startup="ApplicaitonStartUp" 。
在 ApplicationStartUp() 事件处理程序中:
* 加载您拥有的任何松散 XAML
* 创建控制器
* 创建主窗口
* 创建模型
* 将控制器连接到模型和主窗口
* 显示主窗口
*(将模型、控制器和主窗口保存到此处的私有字段中,以确保它们都保持活动状态)
6. 将样式(颜色、字体)添加到 ResourceDictionary 下的单独 XAML 文件中(为此使用混合或购买现成的 XAML主题/皮肤文件)。
想要用 C# 而不是 XAML 编写 UI 的冲动实际上只是表明您对 XAML 的适应程度。
对我来说,编写尽可能少的代码隐藏是个人目标。简单地说,后面的代码很难进行单元测试,但可以(并且通常会)包含未经测试的逻辑。XAML 是声明性的(如 HTML),不包含任何逻辑,因此无需进行单元测试。我将视图代码保存在 XAML 中,并将视图逻辑保存在非常容易测试的 ViewModel (MVVM) 中。
一旦您对 XAML 更加熟悉,您就会越多地意识到它相对于过程代码中的视图构造的好处……使用像 MVVM 这样的模式,您会更进一步,并意识到代码隐藏仅在极少数情况下有用。
要记住的最重要的事情是 XAML 用于演示。您的所有演示文稿都应该在 XAML 中。如果您有逻辑,则将其保留在您的 XAML 之外 - 在您的 C# 中。
想象一下,将您的 XAML 文件换成一个看起来完全不同的文件——但仍然使用相同的数据——这就是划分的地方。
XAML 的优点之一是表示与逻辑的分离。这种分离不仅是理论上的,也是实际的。我的情况是,我的大部分用户界面现在都由设计师处理。这位设计师使用blend,不懂C#,对学习c#没有兴趣,坦白说应该不需要。这位设计师是一位真正的设计师,一位艺术家,他知道如何使用这些工具让事物看起来非常非常漂亮。基本上我的原理是这样的,我使用 XAML 的次数越多,我在 UI 上要做的工作就越少,因为他可以做到。这对我们来说效果很好。我通常将我的控件设计为不显眼,给它们一个基本的简洁外观,使用 DataContext 绑定我的对象(顺便说一句,DataTriggers 是减少代码的好方法)。结果,我会经常检查我的代码,第二天回来,同步它,
当然,至少花了 1/2 年才到那里,但现在这个模型似乎工作了,我们的 UI 看起来 Kick A##,我们的应用程序赢得了很高的评价,我在 UI 本身上做的很少,然后开始工作更酷的东西。长话短说,我认为背后的代码可能更加以开发人员为中心,而忘记了可以使用 WPF 受益、努力和谋生的整个其他群体,即设计师。
当然,有时仍然需要开发人员才能让 XAML/WPF 唱歌跳舞,有时我们需要教育设计人员正确的做事方式,但我认为它的投资是值得的。大型项目(也许简而言之不是这样)
只要您正在开发一个具有一定复杂性的简单 UI,XAML、MXML 所有这些东西都可以工作。一旦你的 UI 变得复杂和丰富,自动数据绑定将带来更多的麻烦而不是它们的好处。XAML 的目的不是让编程变得容易,而是将 UI 与逻辑分开,以便 UI 的工具可以轻松..
没有数据绑定,没有事件处理程序.. 假设您永远不会再看到您的 XAML 并编写代码..
XAML 是演示文稿。数据绑定不是表示。它的表示逻辑。将所有表示逻辑放在代码后面(数据绑定和处理程序)。开发人员拥有背后的代码,设计人员拥有 XAML。如果您是开发人员并且您正在接触 XAML,那么将该部分移到代码后面。
我们也可以在没有 XAML 的情况下编写 WPF 应用程序..
感谢 Vinoth Kumar R(已经使用 Flex MXML 数据绑定进行了足够的测试)
这不仅与您有关,还与您的团队有关,其中一些人可能是设计师。
如前所述,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,当习惯它时,我相信你会喜欢它。
一个好的教程的链接: 教程 MVVM XAML C#
我最初来自 Web 开发方面,目前正在学习 WPF/Silverlight。对我来说,XAML 模型对我来说比 WinForms 更有意义。我将 XAML 视为 HTML,将 .cs 文件视为代码隐藏。
我喜欢干净的代码,我拥有的代码越少,它就越干净。代码可以用数百万种方式编写,XAML 更具限制性。XAML 擅长在适当的时候减少代码。如果我可以在 XAML 中添加一些东西,我会这样做。工具可以读取 XAML 并用它做一些事情。代码少得多。处理 XAML 的工具和框架将发展并变得更好,与现有 XAML 一起做更多更好的工作。不能这么说代码。XAML 发展得越多,我们就越能以声明方式定义我们的应用程序。
对我来说,使用 XAML 就像使用 LINQ。如果我可以写一个易于阅读的单行语句并让框架决定实现我想要的最佳方式,我感觉很好。我肯定会尽可能多地尝试使用我想要的声明,而不是硬编码我希望它如何完成。F# 是这种范式的另一个很好的例子。
无论您在计算机编程中使用什么编程语言,所有逻辑都应该在代码中。即使在 ControlTemplate 中,XAML 也不应该取代它,尽管它很好,但单元测试和调试代码要容易得多。
似乎还没有答案提到重要的一点: 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 方式将其连接到逻辑。
有些东西在代码中更容易维护或调试。
更不用说您将能够在 Xaml2009 中做更多现在必须在代码中完成的事情。
不幸的是,BAML 不会在 vs 2010 时间范围内完全支持 xaml 2009,因此您无法在 2010 时间范围内编译 xaml。并且将不得不等待更高版本的混合来完成完整的开发设计循环。(晚于 3 个)
道格拉斯
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)。
使用流利的风格在 C# 中编程 WPF 有助于降低代码大小和复杂性。有关在 WPF 中使用流利样式的示例,请参阅此答案。
It's mostly preference I think. I use WPF, since it's easier to structure different screens and separate the C# code logic from the UI. Typically all my logic is structured in another C# library than my UI which is the startup project in WPF or Windows Forms