骨干设计 - 相关的模块化关系答案

【问题标题】：Backbone Design - Related, Modular relationships骨干设计 - 相关的模块化关系
【发布时间】：2015-02-13 01:08:38
【问题描述】：

我正在开发一个大规模的 Backbone 构建。然而，我遇到的压力点之一是：

这是一个标准的循环依赖问题。但是，大多数建议是设置一个管理这些（我目前使用的）的顶级项目。这也使得单元测试变得非常困难，因为程序必须引入每个模型和集合才能对其进行管理。

有没有更好的方法来管理这样的场景？

【问题讨论】：

【解决方案1】：

在这种情况下编写单元测试的一种方法是在您正在使用的模块加载框架中模拟出依赖项的另一端。如果RequireJS 是您选择的工具，我已经使用 SquireJS 取得了一些成功：

也就是说，一旦建立起来，它就是一个黄蜂巢。我们放弃了这种测试技术，因为很难推断实际测试的是什么。

（顺便说一句：不要试图成为一个混蛋，但通常像这样的循环依赖是设计问题的症状。模型必须了解集合的用例是什么？）

【讨论】：

这样我可以执行嵌套属性。例如，我有一个模型（用户）、一个模型（配置文件）和一个集合（配置文件）。假设一个用户可以有很多个人资料。嵌套配置文件很容易，嵌套用户有很多配置文件有点困难（但我找到了一种方法）。问题是这样的：配置文件需要用户（所以它可以创建它），用户需要配置文件（以便它可以创建），配置文件需要配置文件......
我明白了——这是有道理的。如果您正在寻找替代方案，我建议更改设计，以便 Profile 永远不会直接创建 User，而是要求在做任何有趣的事情之前向其提供 User 实例。然而，与此同时，Squire 可用于在测试Profile 时模拟出User 模型定义，并在测试User 时模拟出Profile 定义。希望答案有帮助！
我完全同意改变它。我从不喜欢我正在做的设计。但我还没有找到更好的方法：/
您的回答并没有真正表明除了通常的情况之外不要这样做。我正在寻找更多有助于解决此问题的实用建议和模式。