AngularJS - 为什么在控制器中操作DOM是一件坏事？ [英] AngularJS - why manipulating DOM in controller is a bad thing?

问题描述

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

Its common knowledge that DOM manipulations should not be performed in AngularJS Controller, its very hard however to find why exactly is it a bad thing. All the sources say its difficult to test and because controller should be used for communication between directives, but fail to illustrate with code why this is a bad thing.

从我的理解我认为控制器与指令不同，不与任何特定的HTML相关联，因此控制器所做的所有DOM修改都很可能会失败。这肯定会使开发和测试变得复杂。

From my understanding I would think that controller, unlike directive, is not associated with any specific HTML, hence all the DOM modifications controller would do would very possibly fail. This would sure complicate development and testing.

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

Controller in directives being executed before link functions of child directives would also fail as the controller might not be aware of what the actual HTML of the child directives is. Link is executed after controller function and might modify HTML structure.

我希望我在这里有意义，如果有人能澄清为什么从控制器操纵DOM是一件坏事，也许是一些代码示例或链接，它解释得很好。

I hope I make sense here and if someone could clarify why manipulating DOM from controller is a bad thing, maybe some code exampleor link that explains it well that would be great.

推荐答案

使用代码证明自己的观点更加困难的原因示例是因为短代码片段无法真正表示原因（对于Stack Overflow来说足够短）。这实际上是一种可维护性预防措施。从长远来看，您希望能够独立地独立地改变控制器和视图背后的逻辑，因为否则耦合的控制器和视图对倾向于保持这种方式，并且在不破坏另一个的情况下改变其功能的能力相互限制。一旦您决定更改视图的任何内容，您就有可能在不触及控制器代码的情况下使代码中断。

The reason it is more difficult to prove their point with a code sample is that the reason can't really be represented by a short code snippet (short enough for Stack Overflow). It is really a maintainability precaution. Over the long term, you want to be able to independently alter the logic behind controllers and views independently, because otherwise a coupled controller and view pair tend to stay that way and limit each other in their ability to change their functionality without breaking the other. As soon as you decide to change anything about the view, you have the chance of making your controller code break without even touching it.

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

Testing becomes easier over time because the more tests you have, the more you wish that things were more modular and dependent on as little variables and parameters as possible.

同样，维护推动了这一建议。上面列出的问题可能并不是那么糟糕的开始。但是想象一下，采用一个你没有从头开始构建的项目，并且知道控制器和视图之间耦合背后的所有复杂性，将这个应用程序结合在一起。如果您的应用程序达到数千行代码，即使您从头开始构建它，也不可能知道所有这些错综复杂的内容怎么办？

Again, it is maintenance that drives this suggestion. The problems listed above might not be that bad starting out. But imagine adopting a project that you didn't build from the ground up and know all the intricacies behind the coupling between controller and view that hold this application together. What if your application reaches so many thousands of lines of code that it would be impossible for you to know all these intricacies even if you DID build it from the ground up?

为了更全面地了解为什么设计模式与您提到的设计模式是必要的，您可以参考此谷歌搜索，只要你愿意，就会带你去旅行。并且为了大致了解为什么设计模式甚至存在以及为什么许多人一遍又一遍地建议同样的事情，你可以参考引入设计模式的催化剂之一，克里斯托弗亚历山大。他向我们展示了模式是他们的模式，因为他们运作良好，人们重复运作良好。

For a more general understanding of why design patterns like the one you have alluded to are necessary, you can refer to this google search that will take you on a journey as long as you are willing to take. And for a general understanding of why design patterns even exist and why many people end up suggesting the same thing over and over again, you can refer to one of the catalysts to the introduction of design patterns, Christopher Alexander. He shows us that patterns are what they are because they work well and people repeat what works well.

这篇关于AngularJS - 为什么在控制器中操作DOM是一件坏事？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！