与我们应用交互的API会暴露一些实体。一旦这些实体通过网络传送到浏览器，我们将会把它们保存为数据模型。集合是一组相关的实体，通常有着相同的数据类型。我们使用的工具可能会也可能不会提供通用模型和集合组件，或者他们可能有一些相似但命名不同的组件。API数据建模的目标是近似接近API实体。可以简单地将模型存储为JavaScript对象，将集合存储为数组。

简单地将API实体保存为对象和数组有如下问题：其他组件需要实现调用API，在数据发生变化时触发事件，对数据进行变换。我们希望其他组件可以对模型和数组进行变换以完成他们的任务，但不希望有很多重复代码。最好可以将诸如数据变换、API调用、事件生命周期的公共用代码封装起来，如下图。

将API数据如何加载进浏览器、如何发出命令的实现细节隐藏起来，可以使应用程序在成长过程中变得可扩展。随着我们不断为API增加实体，代码的复杂度也在不断增加。我们可以通过约束与模型和集合组件交互的API来控制代码的复杂度。

我们面临的另一个关于模型和集合的可扩展性的问题是，这两个组件应该被放在什么地方？应用程序是一个大组件，由很多小的组件组成。模型和数据集合可以很好地映射到API，但并不一定能很好地映射到应用的功能。API实体比特定的功能更加通用，而且会有更多功能使用。这就给我们带来了一个开放性问题：在众多组件中我们的模型和集合应该处于什么位置？下面例子中的特定视图继承自通用视图，同一个模型可以传递给任意一个视图。

一方面，相对于组件使用的数据和集合，组件可以是完全范化（Generic）的；另一方面，一些组件是针对特定需求的，他们可以直接实例化对应的数据集合。在运行时用模型和集合配置通用组件带来的好处是有条件的：通用组件必须足够通用，能在多处使用。否则我们不如将模型和组件封装在一起。选择正确的方法可以帮助我们实现可扩展，因为组件不是全部通用或全部特定的。