我们要做的是在视图设计得过于详尽和过于笼统之间取得平衡。我们试着看看如果把视图分
割得太小会出现什么情况。

把界面分割成多个小视图会使得我们在控制器中难以管理、引用和控制。同时，因为每个视
图对应一个自己的文件，创建太多的视图会导致难以定位某块

UI 的视图文件或某个视图逻

辑。

另一方面，我们也不想把视图分割得太笼统，因为这会影响到程序的灵活性。

在这种视图设计下，每个视图都显得太简单。当某些视图需要自定义视图逻辑的时候，某个
视图最后要负责太多逻辑，从而变得难以维护。还有，当设计师要改变

UI 布局时，我们要

重构我们视图和视图布局的定义，这是很乏味的。

合理平衡地设计使得我们很容易在页面上重新布局我们的视图，而不用每次都重新构建。例
如，我们想要增加单独的广告视图，或者日后想要干掉它是很简单的。

在这个版本中，我们按照每个视图角色分割我们的界面。一旦你对这些视图有一个总体的思
路，你很容易拼凑出你的界面，同时真正实现这些视图的时候，你也可以在细节处作调整。
有时候你可能发现某两个视图应该合成一个，或者一个视图定义的过于笼统，应该分割为
多个视图，虽然很纠结，但至少我们现在有了一些基础了。

模型

Models

现在，我们有了基本的视图架构，是时候看看我们的模型。通过观察界面中涉及的不同类型
的动态数据，我们可以得到应用程序所需的各种数据模型。

我们决定只是用两个数据模型

 

— Song (音乐) 和 Station (电台)。当然，我们还可以多定义两

个模型

: Artist (歌手) 和 Album (专辑)。不过，我们只是要配合我们的视图，不想在模型方面

定义的太细。在这种情况下，我们不需要分割

artist 和 album，因为我们的程序不允许用户

通过一个歌手去选择一首歌曲。相反，这些数据时由

station 来组织，歌曲是中心，歌手和

专辑都是歌曲的属性。这意味着我们可以把歌曲、歌手和专辑的数据整合到一个模型中。这大
大的简化了程序的数据结构，当然也简化了后台的设计，以为内我们不需要单独的加载歌
手和专辑。总结来说，这个案例中我们只需要使用两种模型

——歌曲和电台。

存储（数据仓库）

Stores