为什么要保持代码"干净"并在XAML中做所有事情？

Question

保持代码"干净"的好处是什么？

很多时候我在这里看到有关某人试图在XAML中执行等效操作而不是代码隐藏的帖子.他们唯一的理由是他们希望将代码保持在"干净"之后.如果我错了,请纠正我,但事实并非如此:

XAML也被编译成BAML - 然后在运行时必须将其解析为代码.

XAML可能会有更多的运行时错误,因为编译器在编译时不会拾取它们 - 从错误的拼写错误 - 这些错误也很难调试.

已经存在代码 - 无论喜欢与否

InitializeComponent();

必须运行它所包含的.gics文件包含一堆代码,尽管它可能是隐藏的.

这纯粹是心理上的吗？我怀疑是开发人员来自网络背景并且喜欢标记而不是代码.

编辑:我不提议代码而不是XAML - 同时使用 - 我更喜欢在XAML中进行绑定 - 我只是反对尽力避免在WPF应用程序中编写esp背后的代码 - 它应该是融合的两者都是为了充分利用它.

Answer 1

1.设计师的观点

UI通常由设计师使用设计器工具(表达混合和朋友)构建.如果我有这种工作流程,那么如果你在代码隐藏中放入大量与UI相关的代码,它就会失效.至少这是我们的经验.它定义的代码和行为/功能对于设计者来说是不可能的:

• 在大多数情况下,代码仅在运行时执行,而不是在设计时执行.所以设计师在设计时并没有看到完整的故事.
• 设计师不是程序员,只有有限的(如果有的话)编程技能,所以他们很可能无法改进那里定义的UI行为.

此外,我们已经获得了一种经验,即d:DesignInstance, d:DesignData, d:DataContext如果存在代码隐藏,设计人员可以使用模拟设计时数据()来提供模拟设计时数据().

2.开发人员的观点

代码隐藏中的UI相关代码(我假设没有必要讨论将域逻辑置于代码隐藏中的可能性)是不可重用的代码.它是永远绑定到一个特定UserControl/Window/Page的代码.如果我反而会写一个自定义的附加属性或行为,我会得到resuablity加上我让我们的desginers高兴,因为他们也可以使用它.

我在代码隐藏中放入的所有代码都是难以测试的代码.当然,通过将其置于XAML或自定义附加属性中,它通常不会变得更容易.但是根据我在代码隐藏中使用的功能类型,我可以将其封装在可测试(可重用)类中.

在XAML限定外观和行为趋于较少(相对于发问参数)错误比代码容易发生.我不能在代码中尽可能多地在XAML中犯错误.如果我做错了什么,我可以立即在设计师/视觉工作室看到它.当然,这里的工具仍然可以改进.事实上,如果我另外使用ReSharper在提问者提到的XAML中,"拼写错误"的错误几乎是不可能的.我立即突出显示了该代码.我相信标准工具会选择它.XAML是在WPF中定义UI的首选方式,微软已经做出了更大的努力,以确保它比使用代码更符合预期.事实上,我已经花了很长时间在代码上调试内存泄漏和运行时异常,这些代码执行与UI相关的东西,并且可以在很少或没有额外努力的情况下移动到XAML.

如果我放松代码隐藏禁欲,那么我编写混乱和错误代码的风险就更高.有时它只是试图快速破解代码隐藏.我们不止一次遭受这种后果.

使用代码隐藏很少是必要的.一旦习惯了ViewModel驱动的用户界面,对于代码隐藏来说,从来没有一个合理的必要性.把它放在其他地方并不需要太多的努力.那为什么要这么麻烦？

Answer 2

我认为这与此有关

• 可测试性 - 它源于保持视图细化的ModelViewController/MVP/MVVM模式以构建GUI的想法.这样,视图就会有一个绑定到支持演示者类的控件,然后可以轻松测试,而不必涉及GUI.只需通过演示者进行测试,您就可以获得非凡的信心.它也比通过UI测试快得多.
• 与命令式编程相比,转向声明性编程 - XAML是声明式编程.您不需要测试XAML标记.此外,MS代码或多或少保证工作并保持工作.因此,您可以确定initializeComponent不会因您刚刚签入的签入而中断.因此从理论上讲,如果您的代码隐藏没有自定义/手写逻辑,那么您可以在不测试视图的情况下完成任务.

Answer 3

您应该保持所有代码清洁,并将工作从后面的代码移到XAML并不是保持干净它只是移动到它所在的位置.您应该将代码(和XAML是一种代码形式)放在最合适的位置,同时尽可能地遵循OOD原则.