Longhorn 如何转换应用程序

摘要

本文重点介绍 Longhorn 的核心支柱（如 WinFS）将如何改变应用程序的编写方式。本文以 Bug Tracker（Bug 跟踪器）为例，探讨了 Win FS 如何实现捕获和维护上下文元数据的关系。这将催生一类全新的、基于元数据关系构建的应用程序。开始进行不同的思考！

免责声明——Longhorn 仍处于开发过程中，因此情况可能会发生变化。这是一篇概念性文章，探讨了如何使用 Longhorn 技术改变应用程序。我不为微软工作，也从未与 WinFS 团队交流过，但我预计他们会朝这个方向发展。屏幕截图是概念截图，无法使用当前 SDK 构建，因为 WinFS 不支持自定义架构。本文中的想法源于我对基于上下文的通信的设想。

本文无意推销 Longhorn 和 WinFS，也不期望您开始为没有发布日期的平台进行编程。本文的主要目的是探讨标准化元数据存储和关系所带来的价值。我预计将有其他技术提供相同能力的元数据存储和关系管理。

引言

Longhorn 凭借其不同的支柱，在应用程序的设计方式上带来了根本性的哲学变革。WinFS 是一个根本性变革的例子。将数据存储在对象关系存储中，可以描述数据对象之间的关系。这些关系不仅对您的应用程序有用，而且对可以重用相同数据及其相应关系的其他应用程序也有用。

例如，在 Longhorn 中使用一个通用的联系人数据存储，可以让不同的应用程序访问相同的数据。如果我在 Outlook Express 或 Outlook 中保存了一个联系人，我的手机就可以访问它，因为手机已同步到联系人存储。

基于上下文的通信

每次通信都会附带一些元数据或上下文。当你问某人——API bug 是否已修复？ 除非建立上下文，说明是哪个 API bug，否则对方会一无所知。大多数时候，上下文是透明地建立的，这些信息从未被捕获和重用。

原因之一是，大多数通信都发生在应用程序之外。例如，关于如何修复 bug 的重要对话可能通过电子邮件进行，而从未被 bug 跟踪系统完全捕获。下一个修复类似 bug 的开发人员必须从头开始。

基于上下文的通信系统可以帮助您透明地捕获上下文元数据并加以利用。如果我正在查看一个 bug，我应该能够点击相关人员并开始一次对话，这次对话也将被 bug 跟踪器记录。下一个遇到类似 bug 的开发人员将能够访问并利用我们对话中的信息。

查看我的联系人时，我也应该能够看到其他详细信息，例如未解决 bug 的数量、已修复 bug 的数量等。我想要的是对一个人进行全方位的了解，其中信息是从各种应用程序聚合而来的。

信息孤岛

由于每个应用程序都将其信息存储在自己的私有空间中，也会发生信息丢失。例如，Outlook 知道 Jill Doe 的 IM ID 是 jdoe@hotmail.com，但我的 Bug Tracker 无法使用此信息，除非我手动输入。

信息分散在不同的应用程序中，并且缺乏以可用方式共享信息的概念。信息丢失的主要原因之一是信息被不同的应用程序以不同的架构和文件格式存储在不同的位置。

将信息存储在 XML 中也无法解决这个问题，因为没有标准化的 XML 数据存储和定义的架构。

我们需要什么

我们需要一种方法来在应用程序之间共享数据，并维护数据之间的关系。WinFS 的设计就是为了实现这些功能。

WinFS 不仅允许应用程序存储联系人，还允许它们存储可被应用程序读取的数据。这样，两个不同的应用程序就可以共享相同的信息。

由于 WinFS 是一个对象关系存储，它还可以维护其存储的不同数据的关系。例如，它可以将一个 bug 与其联系人存储中的某个人关联起来，也可以关联与 bug 相关联的评论列表。

一切都关乎关系。您需要能够定义明确的实体和实体之间的关系。

这有什么不同

在普通应用程序中，您将用户数据、应用程序设置、应用程序数据、历史记录和日志存储在专有格式或 SQL 数据库中。

这三个方面使之与众不同：

• 数据共享
• 数据架构已定义
• 数据关系已定义

这是一个巨大的进步，相当于 Windows 中向事件驱动编程的转变。开放和共享数据是一个令人畏惧的过程，每个应用程序都必须决定共享多少。一些应用程序可能会选择不共享数据，因为这是一种竞争优势。

如何使用 Longhorn 构建一个 Bug Tracker？

有两种方法可以构建一个更好的 Bug Tracker。查看您当前的 Bug Tracker，找出要集成哪些 Longhorn 技术，或者以 Longhorn 为基础构建一个新的用户模型。本文重点介绍了一种概念模型，即如何设计一个新的 Bug 跟踪应用程序。

Longhorn 启用的 Bug Tracker

一个由 Longhorn 设计的 Bug Tracker 将会利用以下功能：

• WinFS
  • 联系人存储
  • 任务存储
  • 通信历史存储
• 通知和警报系统
• Avalon
• Longhorn Shell

联系人集成

在上图中，我可以看到 Aaron 正在处理的项目、已修复的 bug、未解决的 bug 以及来自 Bug Tracker 系统的其他信息。点击未解决的 bug，我可以看到更多关于它们的详细信息。此外，Longhorn Shell 还会跟踪 Aaron 的在线状态。

结果是对 Aaron 与我之间职业关系的 360 度全景视图。

通信历史

与通信历史的集成使我能够查看 bug 的历史记录。围绕 bug 上下文发生的任何通信都会被捕获并显示在通信历史窗口中，同时也会被 bug 跟踪应用程序存储。

通知和警报

通知使我能够快速了解需要我关注的 bug。Longhorn 的通知系统允许我处理通知，而不会填满我的电子邮件收件箱。

Bug 栈

Bug 可以被视为 WinFS 文件夹中的堆栈。在上例中，Jason Carlson 有 9 个未解决的 bug。

Avalon 屏幕

这是一个使用 XAML 构建的示例问题录入屏幕。 “分配给”组合框从 WinFS 联系人存储中选取联系人。

任务视图

应分配给我的 bug 将出现在任务视图中，我与这些任务的交互将发送回 bug 跟踪应用程序。

我的应用程序会做什么（如果 Longhorn 做了大部分工作）

好问题。让我们回顾历史来寻找答案。在 DOS 时代，像 Word Perfect 这样的 DOS 应用程序需要运输包含视频和打印机驱动程序的多个软盘。在 Windows 下，应用程序将显示和打印机的控制权交给了 Windows，再也不需要运输任何视频或打印机驱动程序。软件有一种填满其所占据的整个空间的方式，所以我确信会有客户需求的新功能出现。

结论

充分利用 WinFS 意味着您放弃了对应用程序使用数据的 100% 控制权。但这也意味着与 Shell 的深度集成，并允许最终用户以各种不同的方式操作信息。通过使用关系和数据架构，Longhorn 允许上下文在应用程序之间被捕获和重用。以前隐藏的信息现在可以以以前不可能的方式使用。问题是——您是否会开放您的数据？