0

Dojo dijit 创建的最佳实践是什么？

  1. 纯粹的声明性方法 (D)
  2. 纯粹的程序化方法 (P)
  3. 两者的结合（D&P）

标准

  1. 最容易维护
  2. 开发速度最快
  3. 最直观
  4. 最棒的表演
  5. 大多数功能和灵活性

语境

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

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

程序化

  1. 将 Dojo 与 HTML 分离，从而保持 HTML 的语义纯度
  2. 将事件处理程序和小部件放在同一个地方，提高可读性
  3. 似乎更容易动态地为属性分配值（例如，使用函数创建唯一 ID）

声明式

  1. 快速开发——直观、隐含的嵌套、像普通 HTML 元素一样定义的小部件
  2. 通过使用 data-jojo-* 属性实现有效的 HTML5
  3. 不保留 HTML 的语义纯度
  4. 事件处理程序来自外部脚本，造成了一些复杂性并降低了可读性
  5. 初始 parseOnLoad 可能会减慢前期小部件设置

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


更新：

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

4

1 回答 1

0

我认为没有最佳实践。就我个人而言，我喜欢结合使用程序化代码和声明性代码。

我认为将表示层与业务逻辑层分开（有点像n 层架构）更有意义。dijit/form/TextBox我的意思是，a和标准<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 中定义一切可能也是最好的解决方案。这些规则并不是刻在某处的石头上的。

于 2013-10-18T18:14:08.537 回答