利用 SVG 在 Web 应用程序中创建客户端图表交互（4）

look_w

劳动分工跟本文的由外而内代码编写一样有趣，并且它的应用都是从技术角度出发的，它们最大的影响可能在管理方面。可以用智能 Shockwave 或 HTML5 canvas 编码产生相同的可视效果。但是这些备选方案没有哪一个能像这里的 SVG 技术那样带来明显的劳动分工。
好于 MVC 或呈现与内容软件工程的基本原则之一是，明智的设计导致不同模块之间的耦合低，这些模块然后可能要被相对独立地进行维护、改进及管理等。这就是模型-视图-控制器和呈现-内容被认为是好东西的主要原因。
SVG 的范围比其他划分要窄得多。但是我发现它特别满足我的工作需要。利用这里的编码，地图专家可以独立于 JavaScript 代码编写者来制作地图。如  所述，两种开发人员之间的链接点就是，对单个地理单元的 XML ID 的认可。很容易为彻底不同的应用程序重用地图 — 大家可能都没设想过地图第一次创建的时候是什么样的 — 或者将相同的脚本代码应用于不同的地图。
这个脆弱的链接可能会比最初更弱。不同的工件可以存活在不同的服务器上，出于安全性或经济原因，只在浏览器中第一次会合。医学图像可能在一个国家被编码为 SVG，诊断知识库在另一个国家开发，将二者合到一起的 Web 应用程序则在第三个国家出现。
定制小部件该主题的另一个变体是，它为基于 SVG 的小部件带来了市场 机会，基于 SVG 的小部件类似于 JavaScript 编码的库的现有小部件。可以用内部脚本（用于创建一些有趣的效果）编写 SVG，但是同时也提供外部应用程序编程界面。这导致一种在小部件生产中利用 SVG 内置优势（可伸缩、高效率，等等）的良好方式。
在  小节中，我提到过 XML 在 HTML 和 SVG 中的不同角色。弄清楚这一区别有助于组织工作。Web 开发人员完全可以自由地使用 SVG 小部件或图表，无需自己知道如何编写格式良好的 XML。相反，SVG 专家可以开发他们的地图，无需负责不同浏览器之间 <embed> 和 <object> 各自不同的约定。
另一种来自其他管理模型的区别也值得解释。像 Java™ 和 C++这样的语言通常按照系统开发人员（他们编写库）和应用程序程序员（他们使用这些库）来进行组织。对于 SVG 也可以这样，HTML5 则更为广泛。但是，至少在 2010 年为 SVG 交付的工件一般是源代码。Java 技术编译 它的库，并强调信息隐藏。根据同样的机制，SVG 的现有实践不保护知识产权。关于牵连（implications）的完整讨论超出了本书范畴。
拓宽 DAAS 趋势随着数据即服务的兴起，SVG 将支持更广泛的可视化，可视化将方便地从特定内容去耦合。在 Web 的早期，惟一支持本文说明的这类交互的工具是图像地图和专有插件。前者编写起来特别乏味，维护起来就更难了。相反，SVG 充当一种更高级别的语言，用于开发广泛的图像效果。
其他主题尽管 SVG 只是 XML 的一个独立分支，但是它已经成长得太大了，要完全了解它不是那么容易了，谈何在一篇文章中详细介绍它的各个方面。有不少主题会让本文读者感兴趣，但是仍然超出了本书范畴。对大多数此类主题，都已经可以找到很好的资料（参见 ）。

• SVG 介绍，包括如何编写 SVG 实例；
• HTML 页面中不同风格的嵌入式 SVG 图像；
• 高级 SVG 主题，包括定制小部件的动画和构造；
• SVG 样式，尤其是与 SVG 结合使用 CSS；
• XML，尤其是那些用于 Web 应用程序的工件（比如 XHTML 和 SVG）的所有权；
• JavaScript
• HTML5

结束语由外而内的 SVG 脚本编程允许高级可视效果，容易编写代码。该技术也鼓励良好的模块化，这最小化了可视元素和作用于这些元素之上的应用程序逻辑之间的耦合。