创建

Dojo dijit 的最佳实践是什么？

标准

我已经与 Dojo 合作了不到一个月，最近我开始使用 dijit 库。dijits 广为宣传的一个方面是，它们可以通过编程方式或声明方式声明。我总是喜欢在了解最佳实践的情况下使用一组新工具，并大致了解哪种方法对特定应用程序具有哪些优势/优势。

下面的信息来自两种风格的一些个人经验，以及我能够找到的参考资料，这不是很多。这个链接是我在官方 Dojo 文档中找到的唯一一个关于这个主题的链接，这篇文章提供了一些外部视角，并基本介绍了每个代码在简单场景中的外观。这两个链接都适用于 AMD 在 1.7 版引入之前的旧版本的 dojo。

关于答复的说明

：请在答复中说明每个标准。随意提出您认为重要的任何其他标准。我绝不是评估最佳实践的专家。

更新：

在浏览了有关此的更多信息之后，我发现了另一篇具有类似想法的帖子，它提供了一些有用的上下文，说明这些风格差异的含义。

我认为

没有最佳实践。就个人而言，我喜欢同时使用编程代码和声明性代码的组合。

我认为将表示层与业务逻辑层分开更有意义（有点像 n 层架构）。我的意思是，dijit/form/TextBox和标准<input type="text" /> HTML元素有什么区别？它们都是表示层的一部分，并且都具有相同的目的。唯一的区别是，一个是自定义元素，而另一个不是。

但另一方面，我认为事件处理和验证是业务逻辑，所以我会把它们放到 JavaScript 中。你也可以将你的dojo/store对象声明为声明性的，这也是我不喜欢的，因为它与我的表示层无关。

现在，回到解决你的观点：

最容易维护：如果我必须更改dijit小部件，那么我可能会查看HTML（关注点分离;表示<-->业务逻辑）。它也更容易找到。例如，如果您知道 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中定义所有内容也可能是最好的解决方案。这些规则并不是刻在某个地方的石头上。