XAML或C#代码隐藏

Question

XAML或C#代码隐藏

use*_*375 45 c# wpf xaml code-behind

我不喜欢使用XAML.我更喜欢用C#编写所有代码,但我认为我做错了.

在哪些情况下,最好使用XAML,何时使用C#？你有什么经历？

Answer 1

Wil*_*ins 71

在C#中创建一个完整的窗口可能是一堆代码.WPF的最大优点是XAML允许您将设计与逻辑分离,从而使代码更容易阅读.

当我需要创建动态控件时,我将使用C#,但我倾向于在XAML中保留我的通用设计,静态故事板,样式,数据窗口等.

缺点是你必须学习两种不同的语言来描述相同的东西.我认为WPF团队决定使用XML作为gui描述语言是不幸的.他们本可以使用更接近C#的语法,从而使学习更容易,更容易打字,更容易上手.我在想像JSON这样的东西,只有C#ON.代码和数据之间确实没有强硬路线.Lisp家伙在70年代了解这一点.不幸的是,XML支持者今天仍然没有得到它. (17认同)
同意.XAML的优点在于它可以在编译时之外生存.换句话说,它更像是HTML.从"Themes"文件夹中的文件中读取XAML变得非常容易,并像配置文件一样调整UI.这有一些惊人的用例.你永远不能用C#做到这一点(更不用说它会创造的安全风险) (5认同)
@Phil - 为什么非程序员会更熟悉XML？有比JSON更多的尖括号:-) (3认同)
@Baxissimo:因为人类阅读和编写比编程语言更容易？虽然我认为他们的想法是使用blend,然后将接口移植到使用XML的开发人员. (3认同)
@Phil,在解释时,将平均声明性XML文件与命令式C文件进行比较并不是有效的比较.在XSLT文件和C文件之间进行更有效的比较,这更有利于C文件.一般来说,我的观点是XML被高估了,并且通常应用于有更好的选项(Ant,WPF等)的地方. (3认同)
没有什么能阻止你在C#中分离设计和逻辑.为什么设计必须使用逻辑上的完全外来语法？ (3认同)
@Baxissimo:使用XML不是为了让非程序员能够设计接口吗？ (2认同)
@Phil,你一定是在开玩笑吗？XML比99%的编程语言更难读写.不同意,尝试向非程序员提供2页C程序和2页XML文件,并询问它们哪个更简单. (2认同)

Answer 2

JP *_*oto 27

在WPF中查看有关MVVM的视频.如果你想围绕如何组织一个WPF应用程序,相对于XAML,代码隐藏和其他抽象的内容,这是一个很好的起点.

在MVVM上+1.认真.它改变了编写WPF/Silverlight代码的方式,并使您的代码真正可测试. (7认同)

Answer 3

Dan*_*ker 14

XAML肯定会走得太远.那些想要在XAML中定义的整个用户界面(包括逻辑,事件处理关系等)的人可能会忽略这一点.

XAML的目的是提供一种通用格式来确定事物的外观.它应该只是描述如何布局,如何在视觉上着色和设计它们.

尝试使用它作为C#其他方面的替代品确实没什么意义,因为C#在编程特性方面具有永久性的先发优势 - 重用(定义类型和函数),引用变量,过程编程和甚至是陈述性或功能性风格.

我个人非常喜欢用Linq表达式组合UI!

最后的荒谬是通过我看到的样本达到的,他们使用工作流操作作为按钮的子代提供Click处理程序,因此整个程序在XAML中.这听起来很"酷",但问题是它比同等的C#或VB.NET程序更难看和难以理解,因此C#中准备使用的所有东西都必须被更冗长,更脆弱的等价物所取代.这种转换为更丑陋的语法实际上没有获得任何东西 - 它是同一个程序,只是更加可怕.XML是通用编程语言语法的不良基础.从大写符号必须写成的事实开始>!

在一个并行的世界中,微软在完成XAML之前发布了C#3.0.XAML团队采用C#3.0对象/列表初始化语法而不是XML作为语法.整个辩论从未发生过.

@Tigraine - 你似乎暗示XAML并不是真的很混乱.我不同意.我发现XAML看起来很糟糕并且可以使用.至少使用代码我可以单步执行调试器,而不必涉及角括号的沼泽. (4认同)
你已经意识到这两者是相当强大的,所以你并不完全不同意.我认为你缺少的是没有必要有第二种语法,为什么要有一个呢？要理解这一点,请考虑如今JSON通常比XML更受欢迎.C#初始化语法类似于C#中的JSON.完全相同的树可以用任意一种来表示,缩进量完全相同.WPF中有一些东西(例如设置Grid),这在一个表达式树中无法完成,但可以采用不同的方式完成(并且可以使用简单的包装函数进行处理). (3认同)
@Baxissimo +1 - 我发现XAML比C#代码(或任何其他语言,如C++,VB,MASM等)更难阅读.XML语法样式可能适用于您永远不必在视觉上阅读的文件内容,但即使阅读C#Designer.cs代码也要容易得多.必须阅读和编写XAML才能使用WPF,这只是微软糟糕想法中的另一个问题. (2认同)

Answer 4

Joh*_*her 11

我的经验是,在C#中有些事情要快得多,而大多数在XAML中做得更快.当需要5行C#代码来执行单行XAML代码时,我很容易选择哪个更好.

你能提供一个例子吗？ (2认同)

Answer 5

Dan*_*rod 8

基本上,XAML用于表达视觉设计,C#用于表达逻辑.

任何视觉设计都应该在XAML中完成,任何逻辑都应该在C#中实现.

- 这使得设计师能够在不担心逻辑变化的情况下进行视觉设计,甚至可以在运行时使用松散XAML替换整个视觉设计.

- 这也意味着您可以替换逻辑或视觉设计而不会"破坏".

- 两者之间的连接应该通过数据绑定和命令绑定来完成.

我使用的做法是:

1.在单独的C#代码中定义模型(业务数据对象模型).

2.在XAML中定义视图的常量部分(图形用户界面的常量部分,例如窗口,菜单......)(最好使用Blend而不是VS).
*这里不要定义样式(颜色,字体......).
*不要在XAML后面的代码中为按钮编写事件处理程序(在大多数情况下),而是使用命令绑定.

3.使用位于不同文件中的XAML"ResourceDictionary"定义模型在视图中的显示方式(用于查看/编辑数据对象的GUI).

- 使用混合编写然后使用VS向XAML添加绑定(VS的Jetbrains'Resharper附加组件将帮助绑定表达式).

- 如果在设计时不知道对象类型,则可以使用"loose-XAML"并将XAML放在一个文件夹中,该文件夹可以在不重新编译的情况下添加/编辑文件.

4.在C#中
创建模型和视图(控制器/视图模型)之间的连接,其中:*根据需要创建视图(对于动态对象)
*数据 - 将视图绑定到模型(将视图的DataSource设置为相关对象)在模型中)
*实现命令
*命令 - 将视图绑定到自身内的命令实现

5.在Application.xaml中,删除StartupUri ="MainWindow.xaml"并添加Startup ="ApplicaitonStartUp".
在ApplicationStartUp()事件处理程序中:
*加载任何松散的XAML
*创建控制器
*创建主窗口
*创建模型
*将控制器连接到模型和主窗口
*显示主窗口
*(保存模型,控制器和主窗口在这里进入私人领域,以确保它们都保持活着)

6.在ResourceDictionary下为一个单独的XAML文件添加样式(颜色,字体)(使用混合为此或购买现成的XAML主题/皮肤文件).

Answer 6

Bri*_*sio 5

想要用C#而不是XAML编写UI的冲动实际上只是表明你在XAML中的舒适度.

对我来说,个人目标是尽可能少地编写代码.简单地说,代码背后很难进行单元测试,但可以(并且通常会)包含未经过测试的逻辑.XAML是声明性的(如HTML)并且不包含任何逻辑,因此没有任何单元测试.我将我的视图代码保存在XAML中,并将我的视图逻辑保存在我的ViewModel(MVVM)中,这非常容易测试.

一旦你对XAML越来越熟悉,你就会越多地意识到它在程序代码中构建视图的好处......使用类似MVVM的模式,你更进一步,并意识到代码隐藏只在极少数情况下才有用.

归档时间：	16 年，4 月前
查看次数：	23141 次
最近记录：	9 年，11 月前