问骨干模型是DTO还是POCO (POJO)？

EN

正如WiredPrairie建议的那样，主干方法(我认为是“聪明的程序员”方法)是将事情分解到单独的组件中。

每个程序员，作为一个人，一次只能考虑这么多代码。如果你试图在你的代码中创建大量的类，你基本上保证了你不会一次把所有相关的部分都保存在内存中。此外，几乎每个人都同意测试是代码可维护性的关键部分，而大型类会抑制测试。

最终，你不想要几个大的类，你想要很多很多的小类一起工作来创建你的应用程序。使用这种方法，您可以很容易地理解您正在处理的类，因为它的大小是可管理的，并且您可能还可以立即将与其交互的每个类的一般工作原理保持在您的脑海中。此外，您可以很容易地编写单元测试，因为每个类只有一个目的，以及一组要测试的(大小合理的)操作。

Backbone很好地支持了这一点；我不能肯定，但我很确定Jeremy Ashkenas从来没有想过任何人在他们的整个站点上只有一个View。相反，我很确定他期望站点(至少是普通站点)将多个Views组合在一起来创建站点。同样，试图用一个巨大的Model来做所有的事情，确实与Backbone的设计方式背道而驰。

有许多方法可以使用Backbone在较小的组件之间“连接点”。例如，如果您确实需要一次保存所有数据，这并不意味着您应该只有一个Model。您可以创建一个处理同步的“主”Model，然后为它提供一系列Collections或其他Models属性。然后，您可以覆盖initialize方法以填充这些Models/Collections，并覆盖主Model的toJSON方法以使用其子模块和子集合的toJSON结果。

或者，您可以覆盖子类上的sync方法(或者像save和fetch这样的单个CRUD方法)，这样当它们尝试fetch/save/whatever时，它们实际上触发了主对象的保存。或者，您可以覆盖Backbone.sync以监视发生的每个操作，并阻止来自子对象的操作。或者你可以..。

重点是，对于任何环境中的几乎任何程序员来说，将许多小部分连接在一起而不是试图在一个地方一次性完成所有事情，这是一个很好的实践。因为Backbone是一个非常强大和灵活的库，它为您提供了很多方法来做到这一点。