我正在为我的 Web 项目使用带有 .NET WCF 服务的 Backbone，我真的希望您对以下内容提出意见。
在编写 .NET WCF 服务时，我有一个包含许多属性和多个数据传输对象 (DTO) 的大模型，每个服务返回我的模型的一部分。我正在使用这些 DTO 将数据返回到 Backbone 客户端。
我想知道，我是否应该为每个 DTO 创建一个 Backbone 模型（它的 url 将是服务 url）？
或者也许我应该创建一个大的主干模型并只填充我拥有的数据（调用服务 A 时用 A 的结果填充模型，调用服务 B 时，继续用 B 的结果填充模型）？
使用 DTO 模型方法，当一个模型包含其他模型中存在的属性时，更改第一个模型将需要我同步另一个模型的数据。
使用一个大模型将需要我覆盖 fetch 和 save 方法，以便该模型能够与多个服务交互，而不仅仅是一个。
您认为 Backbone 应该如何工作？
正如 WiredPrairie 建议的 Backbone 方法（我认为，“智能程序员”方法）是将事物分解为单独的组件。
每个程序员，作为一个人，一次只能围绕这么多代码。如果您尝试在代码中创建大量类，则基本上可以保证您不会一次将所有相关部分“保存在内存中”。此外，几乎每个人都同意测试是代码可维护性的关键部分，而大类抑制了测试。
最终，你不想要几个大类，你想要很多很多小类一起工作来创建你的应用程序。使用这种方法，您可以轻松地理解您正在处理的类，因为它的大小是可管理的，并且您可能也可以同时将与其交互的每个类的一般工作方式保持在您的脑海中。此外，您可以轻松编写单元测试，因为每个类只有一个目的和一组（合理大小的）要测试的操作。
Backbone 很好地支持了这一点；我不能肯定地说，但我很确定 Jeremy Ashkenas 从来没有期望任何人View在他们的整个网站上都只有一个。相反，我很确定他期望站点（至少是正常站点）将许多站点组合Views在一起来创建站点。同样，试图用一个巨人做所有事情Model确实违背了 Backbone 的设计用途。
有许多方法可以使用 Backbone 在较小的组件之间“连接点”。例如，如果您确实需要一次保存所有数据，这并不意味着您应该只有一个Model. 您可以创建一个Model处理同步的“主”，然后给它一堆属性或属性，它们是Collections或其他Models. 然后，您可以覆盖该initialize方法以填充这些Models/ Collections，并覆盖该toJSON主设备的方法Model以使用其子模块和子集合的 toJSON 结果。
或者，您可以覆盖子类上的sync方法（或单个 CRUD 方法，如saveand fetch），这样当他们尝试fetch/ save/whatever 时，它们实际上会触发主对象的保存。或者，您可以覆盖Backbone.sync以监视发生的每个操作并阻止来自子对象的操作。或者你可以...
关键是，对于任何环境中的几乎所有程序员来说，将许多小部件连接在一起而不是试图在一个地方一次完成所有事情是一种很好的做法。因为 Backbone 是一个非常强大和灵活的库，它为您提供了很多方法来做到这一点。