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