.gif)
查询可能不会很快，因为它将从多个分区检索实体。
注意这个方法如何使用NullCommandBus实例来接收来自ConferenceViewModelGenerator实例的任何命令，因为我们只是在这里重新构建读模型。
以前，PricedOrderViewModelGenerator使用ConferenceDao类来获取关于座位的信息。现在，它是自治的，并直接处理SeatCreated和SeatUpdated事件来维护这些信息。作为迁移的一部分，必须将此信息添加到读模型中。在前面的代码示例中，PricedOrderViewModelUpdater类只处理SeatCreated和SeatUpdated事件，并将缺失的信息添加到价格订单读模型中。
从V1迁移到V2从V1迁移到V2需要更新已部署的应用程序代码并迁移数据。在生产环境中执行迁移之前，应该始终在测试环境中演练迁移。以下是所需步骤：
将V2版本部署到Azure的staging环境中。V2版本有一个MaintenanceMode属性，最初设置为true。在此模式下，应用程序向用户显示一条消息，说明站点当前正在进行维护，而工作角色将不处理消息。
准备好之后，将V2版本(仍然处于维护模式，MaintenanceMode为true)切换到Azure生产环境中。
让V1版本(现在在staging环境中运行)运行几分钟，以确保所有正在运行的消息都完成了它们的处理。
运行迁移程序来迁移数据(参见下面)。
成功完成数据迁移后，将每种工作角色的MaintenanceMode属性更改为false。
V2版本现在运行在Azure中。
团队考虑使用单独的应用程序在升级过程中向用户显示一条消息，告诉他们站点正在进行维护。然而，在V2版本中使用MaintenanceMode属性提供了一个更简单的过程，并为应用程序添加了一个潜在有用的新特性。
由于对事件存储的更改，不可能执行从V1到V2的无停机升级。然而，团队所做的更改将确保从V2迁移到V3将不需要停机时间。
团队对迁移实用程序应用了各种优化，例如批处理操作，以最小化停机时间。
下面几节总结了从V1到V2的数据迁移。这些步骤中的一些在前面已经讨论过，涉及到应用程序的特定更改或增强。
团队为V2引入的一个更改是，将所有命令和事件消息的副本保存在消息日志中，以便作为未来的证据，通过捕获将来可能使用的所有内容来保证应用程序的安全性。迁移过程考虑到了这个新特性。
因为迁移过程复制了大量的数据，所以您应该在Azure工作角色中运行迁移过程，以最小化成本。迁移实用程序是一个控制台应用程序，因此您可以使用Azure和远程桌面服务。有关如何在Azure角色实例中运行应用程序的信息，请参见Using Remote Desktop with Microsoft Azure Roles。
在一些组织中，安全策略不允许您在Azure生产环境使用远程桌面服务。但是，您只需要一个在迁移期间承载远程桌面会话的工作角色，您可以在迁移完成后删除它。您还可以将迁移代码作为工作角色而不是控制台应用程序运行，并确保它记录迁移的状态，以便您验证。 为会议管理限界上下文生成过去的日志消息
迁移过程的一部分是在可能的情况下重新创建V1版本处理后丢弃的消息，然后将它们添加到消息日志中。在V1版本中，所有从会议管理限界上下文发送到订单和注册限界上下文的集成事件都以这种方式丢失了。系统不能重新创建所有丢失的事件，但可以创建表示迁移时系统状态的事件。
有关更多信息，请参见本章前面的“从会议管理限界上下文中持久化事件”一节。
迁移事件源里的事件在V2版本中，事件存储为每个事件存储额外的元数据，以便于查询事件。迁移过程将所有事件从现有事件存储复制到具有新模式的新事件存储。