Backbone.js视图的适当粒度是多少？

Question

我正在采用Backbone.js来渲染existing large web app的一个小角落。如果这很顺利，我可以看到Backbone.js正在成长为包含整个应用程序，为有机增长的应用程序提供了一些急需的结构。这是序言。现在出现问题：

我有一个选择框，允许用户选择阅读计划。当选择更改时，视图会更新一些描述性文本，日历界面和一个小部件，以便将今天的读数标记为完整。小部件将在今天的条目中为每个阅读（一个或多个）提供一个复选框，并为一个按钮提供继续到第二天的阅读。 （您可以在the existing app的右侧看到此界面的当前非骨干版本（减去完成方案）。

每个视图的适当粒度是多少？我已经确定了以下“繁琐的位”：

• 标签本身，包含所有包含的控件。
• 选择框
• 描述性文字，响应选择框
• 日历，响应选择框
• 读数窗口小部件，响应选择框，包含：
  • （可选）“开始”按钮，用于激活当前计划。
  • 激活时，一个或多个复选框对应于今天条目中的各个读数。
  • 激活时，会出现“下一步”按钮，完成今天的输入并显示下一个。

每个子弹点都应该有自己的视图吗？只是主要部分（标签，选择框，小部件）？第一个会产生很多观点。第一个似乎可能导致过度复杂的View实现。什么是最好的？

注意：我意识到这可能被解释为一个非常主观的问题，但我仍然围绕着Backbone.js和Javascript / DOM MVC模式，我希望从经验丰富的Backbone.js从业者那里可以看到一个狭窄的“这是有意/最有效的”。谢谢！

Answer 1

通常，视图的粒度将取决于在特定UI的复杂性与视图过度碎片化之间找到平衡。我可能不会将视图用于像按钮那样小的东西（CSS类就是你真正需要的）。

在您的特定情况下，我可能会看到日历小部件的视图 - 因此可以在应用程序的其他位置轻松重用 - 以及整个Devotions选项卡的视图。其余的可以通过事件绑定来完成。

关于模型更新和重新渲染，Backbone的整个想法是将这个问题与视图分开。模型在其属性发生变化时会发出“更改”事件，并且当时正在页面上显示的任何视图，并且正在显示该特定模型的数据，将会通知更改，并且可以自行更新。

Answer 2

您的问题没有明确的答案。您可以查看sproutcore的粒度以获取示例。

您还可以观看http://vimeo.com/17186379，其中Yehuda Katz说明了更新页面不同部分的难度。

查看它的一种方法是检查应该使用不同的模型更改/事件刷新哪个部分，并尝试最小化重新渲染。

对不起，你指出没有好的答案;）