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.

推荐答案

用一个代码示例来证明他们的观点更困难的原因是原因不能真正用一个简短的代码片段来表示(足够短堆栈溢出).这确实是一种可维护性预防措施.从长远来看，您希望能够独立地改变控制器和视图背后的逻辑，否则耦合的控制器和视图对往往会保持这种状态，并限制彼此在不破坏对方的情况下更改其功能的能力.一旦您决定更改视图的任何内容，您就有可能在不触及它的情况下破坏控制器代码.

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屋！