为什么要保持代码“干净”并在XAML中做所有事情?

保持代码“干净”的好处是什么?

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

  • XAML也被编译成BAML – 然后在运行时必须将其解析为代码。
  • XAML可能会有更多的运行时错误,因为编译器在编译时不会拾取它们 – 从错误的拼写 – 这些错误也更难调试。
  • 已经存在代码 – 无论喜欢与否
    InitializeComponent(); 

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

  • 这纯粹是心理上的吗? 我怀疑是开发人员来自网络背景,喜欢标记而不是代码。

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

    1.设计师的观点

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

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

    此外,我们已经获得了一种经验,即如果存在代码隐藏,设计人员可以使用这种方法很难找到提供d:DesignInstance, d:DesignData, d:DataContext数据的方法( d:DesignInstance, d:DesignData, d:DataContext )。

    2.开发人员的观点

    代码隐藏中的UI相关代码( 我在这里假设没有必要讨论将域逻辑置于代码隐藏中的可能性 )是不可重用的代码。 它是永远绑定到特定UserControl / Window / Page的代码。 例如,如果我改为编写自定义附加属性或行为,我会获得可靠性,我会让我们的设计师感到高兴,因为他们也可以使用它。

    我在代码隐藏中放入的所有代码都是难以测试的代码。 当然,通过将其置于XAML或自定义附加属性中,大多数情况下并不容易。 但是根据我在代码隐藏中放置的function类型,我可以将其封装在可测试(可重用)类中。

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

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

    使用代码隐藏很少是必要的。 一旦习惯了ViewModel驱动的用户界面,那么代码隐藏绝对不可能是合理的必要条件。 把它放在其他地方并不需要太多努力。 为什么要这么麻烦?

    我认为这与它有关

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

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

    避免代码隐藏文件应主要针对跟随MVVM的人。 我的观点是:在代码中使用业务逻辑会使View和ViewModel相互依赖(直接或间接)。

    如果仅将代码隐藏逻辑限制为视图本身的行为,则可以通过ViewModel与应用程序完全交互。 这也意味着如果你以某种方式管理业务逻辑在xaml本身(没有委托回ViewModel),这也是错误的。

    更直接地回答这个问题:我看到“在XAML中做所有事情”将所有内容绑定到ViewModel中的ViewModel /所有业务逻辑。

    我认为大多数程序员(特别是那些实践MVVM的人)没有在代码隐藏文件中加入代码的原因是为了利用XAML中的数据绑定,我认为这比编程方式简单得多。 此外,开发人员和设计人员可能更容易使用XAML协同工作(例如,填写设计时数据)。

    WPF和XAML对我来说很糟糕。 动态元素太多,在运行时可以检查 – 这非常糟糕。 因此,在设计阶段使用XAML我知道的所有UI – 如果文本是否为粗体,则连接数据,设置转换器,validation器等。

    我不知道干净代码究竟是什么意思。 如果它是干净的,我会使用干净的代码,如果不是 – 我没有,我也不在乎,对我来说似乎更合乎逻辑。