为什么在控制器中操纵DOM被认为是一个坏主意？
许多人告诉我，在控制器中操作DOM是一件非常糟糕的事情，但这究竟是什么原因。它如何影响您正在制作的应用程序？有哪些最佳实践，以及如何实现？
问题答案：
从技术上讲，控制器应该更小，更紧凑，并且不应使用DOM。控制器仅希望具有在事件上被调用的业务逻辑和绑定级别逻辑。
根据我的观点，“ 您不应该从控制器中操作DOM
”背后的原因是，这仅仅是因为关注点分离。如果您从控制器执行DOM操作，那么它将与您的控制器紧密耦合，并且那段代码将变得不可重用。因此，通过在指令中编写该代码，相同的代码可以轻松地成为可插拔和可重用的组件。您只需将指令标记/元素放在其他地方即可使用相同的DOM操作。
查看指令定义，然后您将分析它只是要与DOM一起使用，因为它在使用preLInk函数渲染它之前为DOM提供了一个控制器，并且还可以在postLink函数中后期渲染DOM
。
另外，指令使您可以使用指令元素，而无需对其进行编译，因为element已经使用jQLite它编译过了，它是angular中使用的较小版本的jQuery。此处无需选择器即可获取指令元素DOM。
-
问题内容： 为什么Catch（Exception）一个坏主意？ 问题答案： 因为当你捕获异常时，你应该正确处理它。而且，你不能期望在代码中处理所有类型的异常。同样，当你捕获所有异常时，你可能会得到一个无法处理的异常，并阻止堆栈中位于较高位置的代码正确处理它。 一般原则是捕获可能的最特定类型。
-
问题内容： 我知道这被认为是不良做法；并且，我希望整理出一份为什么要向第三方供应商提交的原因清单，说明为什么他们不应该在其分析代码的实现中使用它们。 请在下面说明您提出不良做法的理由。 问题答案： 一些较严重的问题： document.write（此后称为DW）在XHTML中不起作用 DW不会直接修改DOM，从而阻止了进一步的操作 （试图寻找证据，但充其量只是视情况而定） 页面加载完成后执行的DW
-
问题内容： 为什么只有知道文件的inode却不搜索链接到该inode的文件却无法访问文件？到文件的硬链接只包含名称和数字，告诉您在哪里可以找到有关该文件的所有 真实 信息的索引节点。当我被告知没有用户模式直接使用inode编号打开文件时，我感到很惊讶。 对于系统而言，这似乎是一种无害且有用的功能。为什么不提供？ 问题答案： 某些操作系统 确实 具有该功能。例如，OS X需要它来支持Carbon F
-
我对redis是新的，所以我不知道更多关于它复杂的技术细节。但是让我把我的场景放在这里：我在同一个服务器上运行两个网站，我希望redis在这两个网站上工作。在搜索中，我发现可以通过如下所示为同一服务器实例上的不同数据库分配不同的索引来做到这一点： 这对我来说是理想的，因为我可以在同一个实例中缓存我的两个数据库。但后来我碰到了多个Redis数据库有什么意义？如何在redis数据库之间进行转换？链接上
-
我找不到这个问题的答案。。。 如果我注入服务容器，如： 那么它的工作原理就和我的一样好： 那么，我为什么不直接注入服务容器，然后从类中获取服务呢？
-
今天当我重新浏览Veracode的时候重新打开了一系列的线路比如... 为什么被认为是“网页中与脚本相关的HTML标记的不正确中和（基本XSS”缺陷）？以及为什么今天突然出现，以前从未在任何其他扫描中出现过。 这似乎对我来说很好，或者如果不是，如何修复/mitagate？