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

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

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

我希望我在这里讲得有意义，如果有人能解释为什么从控制器操作DOM是一件坏事，也许一些代码示例或链接能够很好地解释它，那将是非常好的。

用一个代码示例来证明它们的观点比较困难的原因是，原因实际上不能用一个短的代码片段来表示(足够短，足以导致堆栈溢出)。这确实是一个可维护性预防措施。从长期来看，您希望能够独立地更改控制器和视图背后的逻辑，因为否则，耦合的控制器和视图对倾向于保持这种方式，并限制彼此更改功能而不破坏对方的能力。一旦你决定改变视图的任何东西，你就有机会让你的控制器代码中断，甚至不碰它。

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

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

为了更全面地理解为什么像你提到的那样的设计模式是必要的，你可以参考这个谷歌搜索，它将带你去一个旅程，只要你愿意。为了全面理解为什么设计模式甚至存在，以及为什么许多人会一次又一次地提出同样的问题，你可以参考设计模式引入的催化剂之一，克里斯托弗·亚历山大。他向我们展示了模式是什么，因为它们工作得很好，人们重复那些工作得很好的模式。

如果你看一个曾经那么流行的问题"在安古拉吉思考"，如果我有jquery的背景？你会得到一些提示。

我认为DOM操作的一个最大的因素是既不需要也不需要做，因为在涉及到DOM链接时，Angular使用声明性方法，而不是您将用于直接DOM操作的命令式方法。一些答案详细说明了声明性方法和命令式方法之间的区别。

With jQuery you tell the DOM what needs to happen, step by step. With
AngularJS you describe what results you want but not how to do it.
More on this here. Also, check out Mark Rajcok's answer.

这里还提供了对这个主题更全面的处理，说明性编程和命令式编程之间的区别是什么？

通过这种方法，控制器的实现被简化了，随着代码基数的增加和复杂性的增加，我们开始获得真正的价值。

我的观点有点不同，涵盖的不仅仅是测试。设计人员能够控制HTML布局，否则将通过在角度控制器内部编写代码来接管HTML布局。考虑下面的代码片段(这只是一个简单的例子)

这个例子只是迭代一个集合，并在一个单独的段落标记中打印文章。当然可以在角度控制器中循环集合，并动态生成包含文本的段落标记。它将剥夺设计师修改外观和感觉的能力。因此，如果需要显示文章标题，而不是这样做

设计者现在必须找到角控制器代码来修改DOM操作。只需比较以上两种方法，并猜测哪一种方法将提供更大的灵活性。