我已经与Dojo合作了不到一个月了，我最近开始使用dijit库。 dijits广为人知的一个方面是它们可以通过编程或声明方式声明。我总是喜欢接近一套新的工具，了解最佳实践，以及哪种方法对特定应用具有哪些优势/好处的一般概念。
以下信息来自两种风格的个人经验，以及我能够找到的参考资料，这不是很多。 This link是我在关于该主题的官方Dojo文档中找到的唯一一个，this post提供了一些外部视角，并基本介绍了每个代码如何查找简单方案。在版本1.7中引入AMD之前，这两个链接都适用于旧版本的dojo。
有关回复的说明： 请说明回复中的每个条件。随意提出您认为重要的任何其他标准。我绝不是评估最佳实践的专家。
更新：
在浏览了更多相关信息之后，我找到了another post with similar thinking，它提供了一些有用的背景信息，说明了这些风格差异的含义。
答案 0 :(得分：0)
我认为没有最好的做法。我个人喜欢使用程序代码和声明代码的组合。
我认为从业务逻辑层分离表示层更有意义（有点像n-tier architecture）。我的意思是，dijit/form/TextBox和标准<input type="text" /> HTML元素之间有什么区别？它们都是表示层的一部分，它们都有相同的目的。唯一的区别是一个是自定义元素而另一个不是。
但另一方面，我将事件处理和验证视为业务逻辑，因此我将它们放入JavaScript中。你也可以声明你的dojo/store对象声明，这也是我不喜欢的东西，因为它与我的表示层没有关系。
现在，回到你的观点：
最容易维护：如果我必须更改dijit小部件，那么我可能会查看HTML（关注点分离;演示文稿＆lt; - ＆gt;业务逻辑）。它也更容易找到。例如，如果您知道dijit小部件位于标题下方并且位于按钮上方，那么您确切地知道在HTML代码中查找的位置。如果我们以编程方式创建它，它可以在您的代码中的任何位置。
最快开发：嗯，维护和开发有点相同，但声明性标记的另一个优点是，您编写的标记实际上充当占位符，而您必须以编程方式进行分配每个属性都有一个值。
最直观：我在第一部分（最容易维护）中也解决了这个问题。我还认为，他们还使用了一些标准HTML属性，例如title，value，placeholder，....我认为这不会污染您的HTML标记，但也会提高可读性。
最佳表现：这不是最快的方式，我很清楚。但是利润率非常小，并不是因为这是一个巨大的差异。您还可以通过禁用parseOnLoad并手动解析需要解析的节点来调整它。另一个好处是最终用户“看到”某些东西。例如，如果您编写以下代码：
<select data-dojo-type="dijit/form/ComboBox"></select>
<input type="text" placeholder="Text..." />
最终用户在加载页面时实际看到了某些内容（并且它非常能代表实际结果），即使页面未被解析。当您以编程方式创建所有内容时，用户将看到的唯一内容是白页。
大多数功能和灵活性因为我认为结合声明和编程方式开发，我可以享受两者的好处。你以一种声明的方式阻止你做所有事情（如果把它全部放在你的HTML中，事件处理看起来很麻烦），但我会用JavaScript代码编写它们。
另一方面，当你以编程方式创建一个小部件时，它看起来确实很混乱（这是一种观点），所以我可以在HTML中定义这些内容，这样更容易。
所以最后我喜欢写两者的组合。事件处理程序确实来自外部脚本，但是如果你编写适当的MVC应用程序，它们总是会（因为它是控制器的一部分，而标记本身是视图的一部分）。
我并不是说你必须将所有事件处理程序放在一个文件中，不，多亏了AMD加载器，你可以轻松添加其他脚本。如果将某个窗口小部件（或一组窗口小部件）的所有交互分组到文件中并正确命名，则很容易找到它们。
文件越多，文件通常越小，读取越容易（因此复杂性下降，可读性上升）。你最终可能会得到很多文件，但是如果你正确地命名它们（并且可能记录它们），应该没有问题。
但最后，这是一种意见，可能还有其他意见也比我的好，甚至更好。有时它也取决于具体情况，如果性能确实是最大的要求之一，那么用JavaScript定义所有内容也可能是最好的解决方案。并不是说这些规则被刻在某处的石头上。