1.7.5 开发视图

最终部署和要开发的组件之间通常存在微妙的平衡。在极少数情况下，部署约束很少，设计人员可以自由考虑要开发的组件。物理视图将从开发中演化而来。在更常见的情况下，必须使用特定的目标架构，并且物理视图的元素是固定的。

有几种方法可以将分类器部署为更大应用的一部分。我们可能会构建桌面应用、手机App或网站。由于网络无处不在，所以一种常见的方法是创建一个分类器网站，并通过桌面应用和手机App连接它。

Web服务架构意味着可以向服务器发出请求。响应可以是在浏览器中呈现的HTML页面，也可以是主要服务于手机App的JSON文档。一些接口请求用于提供全新的训练集，其他接口用于对未知样本进行分类。我们将在下面的物理视图中详细介绍架构。我们可能会使用Flask框架来构建Web服务。有关Flask的更多信息，请参阅Mastering Flask Web Development（链接4）或Learning Flask Framework（链接5）。

图1.16显示了构建基于Flask的应用所需的一些组件。

图1.16 要构建的组件

图1.16中显示了一个名为Classifier的Python包，它包含多个模块（module）。顶层的3个模块分别是：

• Data Model：中文是数据模型（由于现在还处于分析阶段，所以这里的名称不是那么Pythonic[14]，我们会在进入实现阶段后再修改）。把处理同一个问题的类放在一个模块中通常是很有帮助的。这使得我们可以单独测试这部分代码，而不受应用其他部分的影响。数据模型是基础，因此我们将专注于这一部分。

• View Functions：中文是界面功能（同样处于分析阶段，名称不是那么Pythonic）。这个模块将会创建一个Flash类的实例来代表我们的应用。它将会定义一些函数，用于处理请求，创建可以展示在手机App或网站上的响应内容。这些函数会提供模型的一些功能，但不会像数据模型本身那么深入和复杂。书中的案例学习不会关注这个组件。

• Tests：我们将会为模型和界面功能创建单元测试。测试是确保软件正常工作所必需的，这是第13章的主题。

图1.16中用虚线和箭头指明了依赖关系。这些可以使用Python特定的imports关键字来阐明各种包和模块之间的关系。

当我们在后面的章节中进行设计时，我们将扩展这个初始视图。在考虑了需要构建什么之后，我们现在可以通过绘制应用的物理视图来考虑如何部署它。如上所述，开发和部署之间存在微妙的关系。这两个视图通常是一起构建的。