Knockout.js 是否符合内容/UI/行为分离的最佳实践？

Question

我已经在网络上工作了很长时间，并且看到了“最佳实践”的演变。我现在相当确信将 HTML（内容）、Javascript（行为）和 CSS（UI）分开是最好的做法。

几个月前，我开始使用 knockout.js 。我确实在其他类似的框架（如骨干或 Angular）中选择了它，因为我遵循的 MVC 培训中的一章是关于淘汰赛的，这个概念吸引了我。然后在网上进行了快速比较之后，它看起来并不是一个糟糕的选择，可以满足我的需求，并且作为一个开始。

但这是我的问题：当我现在查看我的 HTML 代码时，经过几周的项目开发，其中有相当多的淘汰赛绑定，这让我想起了很多旧时代，当时我们（或者至少我）过去常常通过onclick 属性等来进行内联javascript事件处理。

因此，我不确定这 2 个问题是否 100% 适合 SO，但我找不到更好的 StackExchange 网站来提问：

1. 是否使用淘汰赛（或其他框架，因为它们似乎基本上都使用相同的模式）违反“分离规则”？或者它是这个规则的可接受的小步骤？或者它甚至完全可以接受，因为它使用了“数据”属性？

2. 如果这是一种不好的做法，是否有可能通过单独的 javascript 文件进行所有绑定，例如使用 jQuery 来选择控件并将绑定应用于它们？如果在淘汰赛中不可能，是否与另一个框架一起使用？我必须承认，在我做选择的时候，我并没有考虑到这种影响......

感谢您，如果将其移至另一个 SE 站点，我们深表歉意。

Answer 1

我和你有同样的最初保留，但我不得不说，将绑定放在 html 中而不是隐藏在 JS 文件中对我来说似乎好多了，因为现在演示和功能之间的联系已经很明显了.它大大减少了更改某些 HTML 和破坏功能的可能性，因为您不知道有人使用 jQuery 将一些 javascript 连接到元素。

另外，正如您所指出的，我认为使用 data-bind 属性确实意味着它确实遵守了分离规则，但如果您想严格遵守它，请确保所有绑定都与 observables ，在您的视图模型上计算或函数，不要使用任何代码（即检查两个可观察对象状态的可见绑定）。不过我不确定我会不会走那么远。

Answer 2

我猜每个人开始学习 KnockoutJS 都有同样的顾虑。

恕我直言，必须有某种方式将模型（JS 对象）与视图（HTML 标记）连接起来。然后我们应该有一些内容：“当单击该按钮时，使用该参数调用此函数。”或“当 JS 数组为空时隐藏此元素”等等。那么我们如何以一种可读、可重用和干净的方式放置/说/声明该连接。

如果您使用另一个 JS 文件来处理该连接，那么您将拥有大量代码来放置您的连接逻辑，并且您需要知道如何选择您要定位的 DOM 元素。你最终会得到大量代码（可能是很多 jQuery），只是为了让你的 HTML 动态和活（我敢打赌大多数开发人员都参与了很多次）。我没有使用其他库或框架，但我认为它们只会让您的大量代码更有条理。

另一方面，KnockoutJS 使用Declarative Bindings，这是模型和视图之间的链接。它更具可读性，易于插入/拔出，它让您只需专注于编写一个好的 JS 模型对象。

我想真正检查分离想想如果你有时需要改变你的模型，你需要对你的视图做多少改变？反之亦然？

Answer 3

添加到其余的答案，一些提示：

确保您的绑定中没有业务逻辑。任何逻辑（应该是最小的）都应该是“视图逻辑”：只影响视图外观的决策，而不影响它的工作方式。决定每个屏幕显示多少项目是视图逻辑；决定用户是否可以添加另一个项目是业务逻辑。将视图逻辑放在视图模型中而不是视图中是完全可以的，如果它涉及冗长的表达式是可取的。

将“幻数”排除在绑定中的任何视图逻辑之外。如果它是一个可以更改的参数（例如要显示的结果的周数）而不是真正的常量（例如一周中的天数），请将其作为视图模型的属性并在视图中的任何表达式中引用它.