javascript - AngularJS - 为什么在 Controller 中操作 DOM 是一件坏事？

Question

DOM 操作不应该在 AngularJS Controller 中执行是常识，但是很难找到为什么这是一件坏事。所有消息来源都说它很难测试，因为 Controller 应该用于指令之间的通信，但未能用代码说明为什么这是一件坏事。

根据我的理解，我认为 Controller 与指令不同，它不与任何特定的 HTML 相关联，因此 Controller 所做的所有 DOM 修改很可能会失败。这肯定会使开发和测试复杂化。

在子指令的链接函数之前执行的指令中的 Controller 也会失败，因为 Controller 可能不知道子指令的实际 HTML 是什么。链接在 Controller 函数之后执行，可能会修改 HTML 结构。

我希望我在这里说得通，如果有人能澄清为什么从 Controller 操纵 DOM 是一件坏事，也许一些代码示例或链接可以很好地解释它，那就太好了。

Answer 1

用代码示例更难证明他们的观点的原因是，这个原因不能真正用一个简短的代码片段来表示(对于 Stack Overflow 来说足够短)。这确实是一种可维护性预防措施。从长远来看，您希望能够独立地独立更改 Controller 和 View 背后的逻辑，因为否则耦合的 Controller 和 View 对往往会保持这种状态并在不破坏对方的情况下相互限制更改功能的能力。一旦您决定更改有关 View 的任何内容，您就有机会破坏您的 Controller 代码，甚至无需触及它。

随着时间的推移，测试会变得更容易，因为您拥有的测试越多，您就越希望事情更加模块化并且依赖于尽可能少的变量和参数。

同样，是维护插入了这一建议。上面列出的问题一开始可能还不错。但是想象一下，采用一个您不是从头开始构建的项目，并且了解将此应用程序保持在一起的 Controller 和 View 之间的耦合背后的所有复杂性。如果您的应用程序包含数千行代码，即使您从头开始构建它也不可能了解所有这些错综复杂的内容，该怎么办？

要更全面地了解为什么需要像您提到的那样的设计模式，您可以引用此 google search只要您愿意，它就会带您踏上一段旅程。为了大致了解为什么设计模式甚至存在以及为什么许多人最终一遍又一遍地提出同样的建议，您可以引用引入设计模式的催化剂之一，Christopher Alexander .他向我们展示了模式之所以如此，是因为它们运作良好，而且人们会重复行之有效的做法。