我正在使用Backbone.js进行涉及许多不同视图的applciation，其中一些嵌套其他视图，而这些其他视图可以进一步嵌套其他视图。
此外，视图显示取决于模型中的某些属性，例如，某些内容仅在用户已经过身份验证时显示，或者是另一种类型的if-check
来自Adobe Flex的世界，我习惯几乎完全使用标记，甚至是深层嵌套或复合的方式来声明我的观点。 Flex使标记中的组件声明变得轻而易举。
我有点希望能在Backbone的纯视图表示和视图逻辑之间实现相同的分离，但到目前为止，我一直在努力。
这样做的原因是我无法仅使用模板来声明复合视图。因此，我不得不求助于使用BB的render（）方法来实例化子视图并将它们附加到父视图。这没关系...但是如果视图变得非常精细，那么使用JS声明它们是一种矫枉过正，因为我最终会附加纯HTML字符串，这是一个完全混乱。这意味着对那些模板使用模板更好，然后只渲染模板而不是使用JS完成所有的东西。
使用这两种方法只会破坏应用程序中的任何一致性，但我会推动自己做得好，因为我已经阅读了很多（甚至是专业编写的）Backbone代码，并且我看到其他人在努力同样的事情。
如果我无法避免渲染方法的这种分离，那么至少我将不得不放置哪些视图应该用模板呈现的任何边界，哪些不是，或者只是部分。问题是这些标准是什么。
答案 0 :(得分：2)
我的方法是让所有标记都包含在模板中。
我对Backbone Views的概念是它们实际上是控制器。如果您在更传统的Web应用程序框架中考虑Controller，他们的工作是接收事件，编组模型，获取和呈现模板，传入模型以及返回结果输出。
在Backbone中，视图是负责此任务的元素。但是，DOM不是输入/输出介质中的http，而是输入/输出介质。
因此，我认为Views是屏幕上特定UI区域的控制器。他们会监听事件，编组模型，获取和渲染模板，并因此修改DOM。
何时解决生成子视图与在循环中渲染模板的麻烦的决定对我来说相当宽松。
如果它可以在多个视图中使用，我将从中创建一个视图。
如果它有任何影响自身的事件或用户交互，但实际上“父”对象中没有任何内容，我将从中查看。
如果它有任何真实的逻辑，我会从中得出一个观点。
如果它是一个相关的模型或集合，我会从中查看。
但是，在任何这些情况下，视图都不会直接生成HTML - 我总是将标记存储在模板中。