组织演示逻辑

数据层

首先要考虑的是不同层中数据的不同副本。从物理角度考虑，通常存在内存中的数据和数据库或文件中的数据之间的差异。您可以将其视为瞬态数据和持久数据之间的差异。但是，我发现通常不仅仅是这些。即使是内存中的数据也经常出现在两个地方。您通常会发现屏幕上的数据和支持屏幕的某种内存存储中的数据之间存在差异。这可能是从数据库中检索到的记录集（但尚未提交回数据库），或者可能是领域模型。

考虑在文字处理器中处理文档。该文档位于磁盘上，您已在文字处理器中打开该文档并编辑了文档的文本。这会导致内存中的文本与磁盘上的文本不同。现在打开一个对话框来更改某些文本的格式。通常，您可以在对话框中更改格式，但它不会更改底层文本，直到您点击应用按钮。对话框中的格式数据是内存中的数据，但它与主内存中的文档中的数据不同。

我将在本书中使用的术语是屏幕状态、会话状态和记录状态。屏幕状态 是在用户界面上显示的数据。会话状态 是用户当前正在处理的数据。会话状态被用户视为某种程度上的临时状态，他们通常有能力保存或放弃他们的工作。记录状态 指的是更持久的数据，预计在会话之间存在的数据。

会话状态主要在内存中进行操作，但通常存储在磁盘上。现代文字处理器通常会保存恢复文件，以避免因电源丢失或系统崩溃而导致工作丢失。企业应用程序可以将会话状态保存在本地检查点文件中，或者服务器可以在请求之间将状态保存在磁盘上。

在企业应用程序中，会话状态和记录状态之间的特殊区别在于，记录状态在系统的多个用户之间共享，而会话状态是私有状态，仅对正在处理它的用户可见。因此，用户不仅决定将更改保存到更持久的形式，而且还决定与同事共享它。会话状态通常与单个业务事务相关联，尽管它通常跨越多个系统事务，这种情况通常需要 离线并发。

并非所有应用程序都具有会话状态。有些应用程序只有屏幕状态和记录状态 - 任何对数据的更改在保存时会直接写入记录状态。在这些情况下，您可能根本没有会话状态，或者任何更改都会立即写入记录状态，因此会话状态始终与记录状态保持一致。没有会话状态可以极大地简化应用程序，因为您无需担心管理会话状态。在许多应用程序中，用户甚至更喜欢这种方式，因为用户永远不必担心丢失工作。但是，省略会话状态并非全是好事。用户将失去在工作状态下尝试场景并根据需要丢弃场景的能力。它还会阻止人们在多用户应用程序中独立工作。

您还可以获得额外的状态层。例如，会话状态同时存储在客户端层和服务器层。这些状态可以独立更改，尽管通常存在关于它们如何同步的相当严格的规则，这使得管理它们变得更加简单。

额外层的示例是开发人员如何在团队中工作。在这种情况下，记录状态是共享源代码存储库的状态。开发人员本地机器上的工作副本是一种会话状态，存储在磁盘上。在这种情况下，它本身是短暂的。然后在 IDE 中还有其他表示形式。在保存并不断更新内存中语法树的现代 IDE 中，您拥有该语法树，以及屏幕上显示的文本。在这种情况下，存在超过三层，但仍然有用的是考虑开发人员在屏幕上看到的内容、他的私有会话数据以及共享的持久数据。为了有效地推理，我会为每组数据命名，并将它们视为独立的层。特定的应用程序将始终拥有自己的集合，在我的讨论中，我将重点关注屏幕、会话和记录状态这三种常见状态。

大多数情况下，用户一次在一个会话中工作。有时用户会同时在多个会话中操作。这通常会导致混淆，因为一个会话中的更改不会显示在另一个会话中，直到两者都与记录状态同步。您可以通过同步两个会话来解决此问题，但这通常很混乱。

这些多个状态通常对应于企业应用程序的各个层。在一个理想的应用程序中，该应用程序使用表示层、域层和数据源层，您将只有域逻辑在会话状态上运行。在实践中，这种区别变得模糊，通常是由于不好的原因，但有时是由于好的原因。在一个应用程序中，域层与表示层位于不同的进程中，您可能希望在表示层进程中运行一些域逻辑，以使应用程序具有适当的响应能力。这种逻辑可能涉及从主域进程复制一些会话状态，或者您可能需要针对表示层控件中的数据运行域逻辑。同样，如果您需要对大量数据进行操作，您可能需要通过类似存储过程的方式将域逻辑嵌入到数据库中。这种逻辑在记录状态上运行。但是，大多数情况下，您希望域逻辑在会话状态上运行。

层之间同步

在这些不同上下文之间同步数据是构建应用程序的重要部分。当您在用户界面上工作时，您可以将屏幕状态同步到两种不同的深度：会话状态或记录状态。如果您同步到会话状态，您将需要一些控件，允许用户将会话状态保存到记录状态。

同步可以以不同的频率发生，我发现以下三种很有用。**按键同步**意味着您在每次按键或鼠标点击时同步。**字段同步**意味着您在完成字段编辑时同步。**屏幕同步**意味着您在完成一屏信息后，同步一些 UI 中的特殊按钮（通常标记为“应用”、“确定”、“取消”或“提交”）。

一旦您需要同步，下一个问题是您同步多少。当您查看将屏幕数据与会话数据同步时，我看到两种主要方案。**粗粒度同步**意味着无论何时您在 UI 上进行更改，整个 UI 都会同步；因此，更改艺术家字段意味着同步整个窗口，即使没有其他内容需要更改。**细粒度同步**意味着只更改真正需要更新的字段。因此，更改标题字段将涉及同步标题字段、窗口标题和列表框 - 但没有其他内容。

会话数据和记录数据之间的同步通常使用不同的方法。会话数据通常不会被多个人同时使用，因此您不必担心并发问题。会话数据和记录数据之间的同步通常发生在屏幕同步时，并且通常需要更长的时间。因此，您会执行诸如将数据元素标记为脏或使用工作单元之类的操作。

所有这些方面在 UI 的内部设计和交互设计中相互权衡。最明显的权衡发生在同步的频率和深度之间。将按键同步到记录状态会导致不可接受的性能，以及其他弊病。因此，大多数情况下，我看到屏幕同步在该深度使用。实际上，屏幕同步也是会话深度中最常见的。它通常是最容易做到的，并且许多应用程序都是这样工作的，因此用户已经习惯了它。但是，交互设计确实需要字段同步也很常见。如果域逻辑与表示层位于同一个进程中，则字段同步非常容易，如果它位于不同的进程中，则获得良好的性能会更加困难。因此，对于域层，屏幕同步是一个合理的默认值，但预计会相当频繁地进行字段同步。

按键同步似乎比较少见，但如果域位于同一个进程中，则很容易实现。

虽然时间选择会随着深度和应用程序设计的不同而有所不同，但我几乎总是赞成屏幕和会话状态之间的粗粒度同步。许多人回避粗粒度同步，因为他们担心性能影响。但是，细粒度同步很难维护，因为有很多代码重复出现。所有这些代码中的错误都很难发现，因此也很难修复。大多数情况下，粗粒度同步的性能足够好，因此我的建议是始终先使用它。如果您确实遇到了性能问题，并且您已经通过分析来检查它确实是同步问题，那么您必须引入一些细粒度同步来解决它。此时，只需执行解决性能问题的最小操作即可。

这种同步需求非常普遍，因此人们不可避免地会开发框架来尝试处理它。一个备受关注的框架是 .NET 中的数据绑定框架，它会自动同步屏幕和会话状态。数据绑定具有许多优点，理论上应该能够很好地处理同步。到目前为止（截至 1.0 版），我发现它在简单情况下运行良好，但在中等复杂的情况下会失效。我与之交谈过的开始使用数据绑定的项目最终都放弃了，因为没有足够的方法来控制绑定的工作方式。因此，我建议谨慎使用它，除非您的需求非常简单。但是，在更高版本中重新评估它 - 我很容易看到它会变成一个非常有效的解决方案，可以解决同步问题。

同步和多个屏幕

同步的一部分是关于在状态层之间同步，另一部分是处理在同一层的多个线程之间同步。您经常会在单个记录状态之上找到多个会话，以及每个会话之上的多个屏幕。每个都是一个独立的上下文，您必须考虑一个上下文中的更改如何传播到其他上下文。

由于我在这里谈论的是演示，因此我不会过多地讨论同步多个会话。无论如何，这是一个更容易理解且相对简单的主题。大多数情况下，会话彼此隔离，并且只与记录状态同步。它们使用事务或某种形式的离线并发控制来执行此操作。

演示更复杂，因为用户期望更少的隔离和更快的同步。

如何最好地同步多个屏幕在很大程度上取决于屏幕的组织方式以及屏幕之间流动的结构。从两个极端来看，我们可以考虑对比向导与完全非模态的界面（例如文件系统资源管理器）。

使用向导用户界面，系统会引导用户完成一个非常受控的屏幕流程。在任何时候，只有一个屏幕可见，并且通常用户只能从每个屏幕向前或向后移动。在这种情况下，屏幕的设计者确切地知道显示了哪些数据，以及何时打开和关闭屏幕。

使用文件系统资源管理器，用户可以随意在屏幕之间移动。更重要的是，用户可以打开多个资源管理器窗口，显示相同的文件。如果用户在一个窗口中更改了文件夹的名称，其他窗口也应该更新。UI 的程序员永远不会真正确定何时会打开窗口，以及是否在多个窗口中显示了相同的数据。

这两个极端表明了在屏幕之间协调信息的两种不同方法。使用流程同步，每个屏幕都会根据应用程序的流程决定何时将其屏幕状态与任何底层会话状态同步。因此，对于向导，屏幕通常会在从一个屏幕移动到另一个屏幕时同步；写入旧屏幕并读取新屏幕的数据。流程同步在屏幕之间的流程很简单，并且存在明确的点可以将数据从屏幕状态保存到会话状态并加载到会话状态时效果最佳。

对于文件资源管理器，流程同步将很困难。一个屏幕永远无法真正确定另一个屏幕是否已更改底层数据。在这种情况下，屏幕需要彼此不知情，并在底层数据更改时同步。使用观察者同步，底层屏幕状态充当数据的母版源。每当它发生更改时，显示它的屏幕都会收到通知，并可以更新其屏幕状态，通常使用观察者模式。在这种形式下，观察者同步是模型视图控制器样式的基本组成部分。

关于观察者同步的好处是，所有屏幕始终彼此完全独立，既不需要彼此了解以进行同步，也不需要彼此告知同步事件。这使得在应用程序中拥有非常临时和复杂的流程变得容易。观察者同步的缺点是它依赖于使用观察者，并且会引入一些隐式行为，如果您让它失控，可能会变得非常棘手。

然而，总的来说，观察者同步是复杂 UI 的主要选择。流程同步实际上只有在应用程序流程非常简单时才可以使用：通常一次只有一个活动屏幕，并且屏幕之间的流程很简单。即使这样，一旦您习惯了观察者同步，您可能更愿意即使对于这些简单情况也使用它。