Backbone.js 主干/JS最佳实践：初始化模型内部视图是好还是坏？

我的主干。视图看起来是这样的：

define(["promise!table_config", "BBModel"], function (config, myModel) {
    "use strict";

    return Backbone.View.extend({
        initialize: function () {
            this.model = new myModel({
                foo: config
            });
            ...
        },
        render: function () {
            ...
        }
    });
});

在视图中初始化模型是好的还是坏的做法？

---

特别是在这种情况下，在require.js模块中，“config”是一个，这促使我将模型放在视图中。

虽然主干有一个

模型和
视图
类，但它不是一个严格的MVC框架（例如，它缺少
控制器
类）。主干文档页面解释了以下内容（我的重点）：

主干网与“传统”MVC有什么关系

模型-视图-控制器模式的不同实现往往不一致
关于控制器的定义如果有帮助，在主干中，
View类也可以看作是一种控制器，
使用HTML模板调度源自UI的事件
作为真实的视图。我们称之为视图，因为它代表
UI的逻辑块，负责单个DOM的内容
元素

考虑到这一点，即使（正如@Evgenly在评论中提到的）“它的视图职责不是实例模型，它的控制器任务”。。。由于主干
视图
在概念上是一个控制器，因此在视图中创建模型绝对有意义

但抛开这个理论不谈，这里有一个更实际的答案。我和另外两名开发者（以及之前更多的开发者）一起开发了一款3年多的主干应用程序。在该应用程序中，绝大多数模型都是在视图内部创建的（剩下的少数模型是在路线内部创建的）。这不仅对我们来说不是问题，而且我甚至无法想象有任何其他的方法来做到这一点。
我不认为它对实例模型的责任，它的控制器任务。这也是我的假设。但假设我在这种情况下被迫这么做。例如，从应用程序架构的角度来看，未来会有什么后果。最重要的是这三点：1）难以测试2）视图类型和模型类型之间的紧密耦合。3） 几乎不可能在不同的视图之间共享相同的模型。同意，纯BB视图因控制器的部分职责而过载。但它并没有放弃使用新的抽象特性来扩展BB，该特性可以处理控制器角色。例如-Backbone.marinonete.Controller-大致上，它的和对象从BB.Events扩展而来，并保留API方法的散列。从这个角度来看，我们不应该限制我们自己的BB工具从盒子和扩展它的抽象组件，我们需要的，此外，BB的灵活性为我们提供了相当明确的方式来做到这一点。