我对 WPF 和 XAML 了解得越多,我就越意识到您可以在 XAML 或代码(例如 C# 代码或 VB.Net 代码)中完成几乎所有的 GUI 初始化和事件处理粘合。
我的问题是那些在 WPF 上工作了更长时间的人,最好是那些已经使用它发布应用程序的人——你在哪里找到了在 XAML 和代码之间“划清界限”的最佳位置?您是否尽可能使用 XAML?仅在哪里与非编码 UI 设计师交互?
这方面的任何提示都会对我自己和其他刚刚进入 WPF 编程并且对我们可以做出的所有选择感到瘫痪的程序员非常有帮助!
我要看的一件事是模型-视图-视图模型模式。这是一个非常优雅的模式,它自然地将所有内容分成漂亮的桶......包括你的 xaml。
例如,它可以帮助您在开发人员和设计人员之间保持清晰的界限,甚至允许测试驱动的开发。
那里有很多信息,但我将从 John Gossman 的博客文章开始:
更新: 只是想将人们指向另一个 StackOverflow帖子,其中包含很多关于 MV-VM 的好信息。
一个提示是不要在 XAML 中声明事件处理程序。相反,在代码隐藏中命名您的元素并附加事件处理程序。这有助于在设计人员和开发人员之间保持清晰的分离。
正如其他人建议的那样,尝试遵循 Model-View-ViewModel 模式。但是,将东西放在代码隐藏中是可以的!规则是,如果它与“视图”相关,则将其放在 Xaml 或代码隐藏中(以您更方便的为准)。如果它更多的是与用户如何与系统交互相关的业务逻辑,那么它属于 ViewModel。如果只是业务逻辑不关心交互,它属于模型。
每一个的例子是:
Model:定义一个名为 ModifiedDate 的属性,用于存储上次修改的时间。
ViewModel:根据修改时间将 ModifiedDate 转换为名为 ModifiedAge 的枚举属性:昨天、上周、上个月、去年等。
View:将 ModifiedAge 属性转换为背景颜色,其中最近访问的数据以亮黄色突出显示,而最近访问的数据更多的是米色-卡其色,您的设计师坚持称为“Meadow Lark Lilly Flowerpot”。
另一个技巧是将 XAML 分为功能性和美观性。开发人员通常会在功能 XAML 中工作,而设计人员主要关心美学。这使得功能 XAML 非常易于理解,这很重要,因为开发人员经常需要编辑此类 XAML。Aesthetic XAML 通常由设计人员使用工具进行编辑,因此其简洁性和冗长性不是问题。
不久前,我在这里写了一篇关于此的博客文章。
不要忽视 XAML是代码这一事实。它是声明性的,但它仍然是一种编程语言。事实上,它在转换为 IL 以供 .NET 编译器使用之前,会先转换为 C# 或 Visual Basic。
我将回应 Scott Whitlock 的评论:MVVM 是一种很好的方式来分离关注点并专注于架构细节。把东西放在你的代码隐藏中真的非常好,尤其是他描述的东西。如果您不需要将设计人员与开发人员分开,请根据您的特定需求调整 MVVM 模式;不要试图强迫自己对此保持纯粹或理想主义。
如果您不需要使用 ICommand 类进行命令的灵活性,也可以在后面的 View 代码中直接调用 ViewModel 的方法。或者,如果您知道您正在制作的 View 将始终绑定到您正在制作的 ViewModel 类。或者您可以更进一步,为您的 ViewModel 定义一个接口,并仅绑定到该接口的实现。然后,您仍然可以随时更换 ViewModel。
像这样的东西。
当您遵循像Mode-View-ViewModel这样的正确模式时,您将有机会在 XAML 方面做更多事情,而在代码背后做更少。最大限度地利用 WPF 代码中的RoutedEvents和Commands。
在构建 UserControls 时,我尝试尽可能地进行 Xamlize。
我在该领域发现的一个提示是,手动创建ControlTemplate真的DataTemplates很痛苦......我总是用 XAML 编写这些......
我想说尽可能多地使用 xaml,使用Binding, commands,styles等templates。我必须支持使用 XAMLReader/XAMLWriter 保存和加载模板的功能,并且对于具有更多 xaml 的控件来说更容易。