AngularJS - 為什么在控制器中操作DOM是一件壞事？

Question

眾所周知，DOM操作不應該在AngularJS控制器中執行，但是很難找到為什么它確實是一件壞事。 所有消息來源都說它難以測試，因為控制器應該用於指令之間的通信，但是沒有用代碼說明為什么這是一件壞事。

根據我的理解，我認為控制器與指令不同，不與任何特定的HTML相關聯，因此控制器所做的所有DOM修改都很可能會失敗。 這肯定會使開發和測試變得復雜。

在子指令的鏈接函數之前執行的指令中的控制器也將失敗，因為控制器可能不知道子指令的實際HTML是什么。 鏈接在控制器功能之后執行，可能會修改HTML結構。

我希望我在這里有意義，如果有人能澄清為什么從控制器操縱DOM是一件壞事，也許一些代碼示例或鏈接可以很好地解釋它。

Answer 1

使用代碼示例更難以證明自己的觀點的原因是，原因無法真正用短代碼片段表示（對於Stack Overflow來說足夠短）。 這實際上是一種可維護性預防措施。 從長遠來看，您希望能夠獨立地獨立地改變控制器和視圖背后的邏輯，因為否則耦合的控制器和視圖對傾向於保持這種方式，並且在不破壞另一個的情況下改變其功能的能力相互限制。 一旦您決定更改有關視圖的任何內容，您就有可能在不觸及控制器代碼的情況下使控制器代碼中斷。

隨着時間的推移，測試變得越來越容易，因為您擁有的測試越多，您就越希望事物更加模塊化，並且盡可能少地依賴於變量和參數。

同樣，正是維護推動了這一建議。 上面列出的問題可能並不是那么糟糕的開始。 但是想象一下，采用一個你沒有從頭開始構建的項目，並且知道控制器和視圖之間耦合背后的所有復雜性，將這個應用程序結合在一起。 如果您的應用程序達到如此多的代碼行，那么即使您從頭開始構建它，您也無法知道所有這些錯綜復雜的內容怎么辦？

為了更全面地了解為什么設計模式與您提到的設計模式是必要的，您可以參考這個谷歌搜索 ，只要您願意，這將帶您踏上旅程。 為了大致了解為什么設計模式甚至存在以及為什么許多人最終會一遍又一遍地提出同樣的建議，你可以參考其中一個催化劑來引入設計模式， 克里斯托弗亞歷山大 。 他向我們展示了模式就是它們的原因，因為它們運作良好，人們重復運作良好。

Answer 2

如果你看一個如此流行的問題“Thinking in AngularJS”，如果我有一個jQuery背景？ 你會得到一些提示。

我認為DOM操作既不需要也不需要完成的最大因素之一是因為當涉及DOM鏈接時，Angular使用聲明性方法，而不是使用直接DOM操作的命令式方法。 一些答案詳細說明了聲明式和命令式方法之間的這種區別。

使用jQuery，您可以一步一步地告訴DOM需要發生什么。 使用AngularJS，您可以描述所需的結果，但不能描述如何執行此操作。 更多關於這里。 另外，請查看Mark Rajcok的答案。

此處還可以對此主題進行更全面的處理。 聲明式編程和命令式編程之間的區別是什么

通過這種方法，控制器實現得以簡化，隨着代碼庫大小的增加和復雜性的增加，我們開始獲得真正的價值。

Answer 3

我的觀點略有不同，涵蓋的不僅僅是測試。 設計人員能夠控制HTML布局，否則將通過在Angular Controller內編寫代碼來接管。 考慮以下片段（這只是一個簡單的例子）

<div ng-repeat="article in articles">
    <p class="article-body">{{article.text}}</p>
</div>

此示例僅迭代集合並在單獨的段落標記中打印文章。 雖然可以在Angular Controller中循環遍歷集合並動態生成包含文本的段落標記。 它將剝奪設計師修改外觀和感覺的能力。 因此，如果需要顯示文章標題，而不是這樣做

<div ng-repeat="article in articles">
    <span class="article-title">{{article.title}}</span>
    <p class="article-body">{{article.text}}</p>
</div>

設計人員現在必須找到Angular Controller代碼來修改DOM操作。 只需比較以上兩種方法，並猜測哪一種方法將提供更大的靈活性