为什么要用最少的用户/手写代码来完成XAML中的所有工作？

12

我觉得MVVM社区已经像90年代的OO程序员一样变得过分热情-这是一个错误的称呼MVVM是没有代码的代名词。从我关闭的StackOverflow问题中：

我多次在这里遇到有关某人试图在XAML中完成等效操作而不是在后面编写代码的帖子。他们唯一的理由是他们希望将代码保持在“干净”的后面。如果我错了，请纠正我，但事实并非如此：

XAML也被编译为BAML，然后无论如何在运行时都必须将其解析为代码。XAML可能具有更多的运行时错误，因为编译器在编译时不会从错误的拼写中拾取它们，这些错误也更难调试。后面已经有代码-是否喜欢InitializeComponent（）; 必须运行，并且其中的.gics文件包含一堆代码，尽管它可能是隐藏的。这纯粹是心理上的吗？我怀疑是开发人员来自网络背景，喜欢标记而不是代码。

编辑：我不建议在XAML后面编写代码-两者都使用-我也希望在XAML中进行绑定-我反对采取一切措施避免在WPF应用程序中的esp后面编写代码-这应该是两者都可以最大程度地发挥作用。

更新：这甚至不是微软的想法，MSDN上的每个示例都展示了如何在两者中都可以做到。

c# wpf

— 标记
source

9

我从未听说有人建议将所有内容都放入XAML。

实际上，这是一个可怕的想法，海事组织。

从历史上看，问题出在Winforms应用程序，其代码中的逻辑后面不存在逻辑，因为这是逻辑。这就是VM重要性的来源。它允许您隔离将视图与模型联系在一起的零件。

因此，视图仅用于处理最擅长的是UI。

现在，如果您碰巧遇到UI需要代码的情况，那么请务必将其放入代码中。但是，我要说的是，对于95％的场景，最好将UI留在标记文件中，如果需要后面的代码，则可能是在尝试写一些逻辑这更适合留给视图模型。诸如行为之类的东西是例外，但是它们完全是分开的动物，并且需要特殊的位置（即不在后面的代码中）。

— 约瑟夫
source

“没有代码……永远”是一条规则……规则应在正确的情况下被打破

— WernerCD 2010年

1

为了直接回答您的问题，并假设当您说“代码”时，您在每种情况下都专门指代后台代码（可视控件类上的代码），原因是这样可以完全实现您的用户界面并仅使用一种技术在Blend中进行操作。假设您的UX设计师不是开发人员，也不希望在代码中工作，并且他们是布局和XAML专家，而不是编码专家。如果您在不使用任何代码的情况下实现所有工作，则可以为这类设计师提供他们完全可以使用其语言工作所需的工具。

它提供了命令式编程和声明式设计之间的清晰区分。

这是Silverlight和WPF中存在“行为”的驱动原因-与其将一些代码塞入背后的代码中，而应将行为变成自己的可重用模块。如果这样做，Blend将为您带来真正的好处，即可以将其拖放到控件上。现在，您已经将移动部件抽象到一个不错的容器中，可以使用设计器工具对其进行操作，而不是将其一次性移动部件转移到原本在XAML中的所有控件。

— 纳拉沃克
source

1

以我的经验，这通常归结为试图在XAML触发器中使用复杂的逻辑，以将其排除在代码之外，而更好，更简单的方法是将这两种逻辑都不放在其中-它属于视图-模型。

— 杰伊
source

1

在xaml中做所有事情的最大优点之一是，它将所有行为都放在一个地方。每次开发人员不得不在xaml和代码之间切换时，就会变得更加难以理解。

我曾经在WPF团队工作过，但没有将减少代码隐藏作为优先事项。不止几次，调试工作变得更加困难，因为某些事件处理程序正在操纵控件，并且由于行为分散在两个文件中，所以并没有立即显现出来。

就是说，我认为您认为某些时候最好妥协于设计原则是正确的。有些事情在xaml中很难完成。我已经花了几个小时甚至几天来尝试使一种行为能够在xaml中工作，而使用隐藏代码可以在更少的时间内完成。我已经把代码隐藏作为最后的手段，但是我永远不会告诉别人他们永远不要使用它。这只是一个好的工程师需要理解的另一个权衡。

编辑：从评论听起来我的帖子被解释为反对xaml。我的意图是提出相反的意见。纯xaml总是可取的，因为它将所有行为都集中在一个地方。xaml和后台代码的混合可能令人费解，因此最小化后台代码是理想的。由于许多原因，Xaml优于纯代码隐藏。WPF和Silverlight设计为以xaml编写。

— 德鲁
source

2

根据此逻辑，我们还可以再次用纯代码实现所有内容。

— Steven Jeuris 2011年

@ Steven Jeuris在某些方面，最好是将xaml和代码分散在一起。我已经看到它纯粹是在代码和工作中完成的。

— 德鲁

从纯粹的程序员角度来看，我同意。但是，关键是XAML使得开发人员可以轻松开发工具，而设计人员可以将其与代码完全分开。

— 史蒂文·杰里斯

@Steven Jeuris：我完全同意。只要有可能，我都会在xaml中进行所有操作。这就是我在帖子中所说的意思：“我已将代码隐藏作为最后的选择。” 我试图争辩说，更少的代码隐藏总是总是更好的。我的目标是说纯xaml是最好的，但是像大多数设计原则一样，在极少数情况下可以妥协并闯入代码背后。

— 德鲁

1

我对XAML仅有非常肤浅的知识，但令我感到困惑的是，编译器无法检测到拼写错误。

基本区别是XAML是声明性的，而C＃例如是命令性的。

简单的说：

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

与

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

上面的代码实际上通过副作用创建了一个层次结构，而下面的代码只是简单地声明了它。还值得注意的是，尽管例如addChild可以重命名该方法，但子-父母-关系是语义模型的核心，并且在声明性代码段中也是如此表示。它与实现相差很远，后者允许完全透明地进行很多优化，例如延迟实例化。
声明式编程具有许多优点。它更简洁，更具表现力，并且非常接近您的模型。我会尽其所能。

但是，这并不意味着您应该尝试将所有内容都打入XAML。C＃具有许多允许声明式样式的高级构造。

最后，您希望您的代码简短易读。因此，如果您可以用比XAML更少的代码在C＃中实现相同的目的，那么使用C＃是合乎逻辑的。请记住，但是，XAML代码更容易“移植”，因为它不易受到所用组件更改的影响，从而使.NET框架抽象化（例如，有关如何实现绑定的详细信息）。

— back2dos
source