wcf - WCF + CQRS + 推送通知

Question

我必须设计一个连接到 WCF 服务的客户端系统，以对数据库执行读写操作，并获取通知。

有人告诉我使用 CQRS 模式。

举个例子，客户端将连接到服务以执行诸如获取产品列表和更新产品之类的操作。他们还可以执行诸如接受货件和拒绝货件之类的操作（这可能会导致首先执行此操作的客户之间发生竞争）。只有一个客户可以“接受”货物或“拒绝”货物。

所以我读了一点关于 CQRS 的内容，并理解它使读取与写入分离（使用命令）。但是，如果我使用 CQRS，我不确定一些主要问题：

1. 如果我在 WCF 服务上使用 CQRS 模式 - 我可以指望在数据库上同步完成的事情吗？我有点困惑，因为我不希望服务是单线程的（以支持未来的可扩展性），但另一方面 - 我如何确保服务上的写操作以正确的顺序执行？甚至读操作？CQRS 模式是否保证有序处理？（有人在这里告诉我，CQRS 模式使用“更新”队列来更新脱机处理的请求）。

2. 使用 CQRS 可以消除并发问题吗？

3. 我是否仍应在与数据库交互的所有命令处理程序中使用“TransactionScope”？

4. 我花了一个多星期的时间试图了解如何为客户实施通知服务，但没有运气。我有这个设计：

“产品服务”将是 CQRS 服务，但通知服务有问题。客户端可以向产品服务发送命令以通知 X 类产品。该命令将更新数据库中的请求。现在假设通知服务每 15 分钟轮询一次数据库，并检查哪个用户希望轮询哪个类别，然后将新产品发送给请求就这些产品类别进行通知的用户。如果用户更改了产品的类别并且其他 20 位用户已经在他们的通知窗口中看到了该产品，现在会发生什么情况？我需要某种方法来检测产品不再属于该类别，并向他们发送通知，例如'从您的视图中删除该产品'。这听起来不太像通知。这听起来更像是“请求数据库表的 CONSTANT RELEVANT 视图，并且每个更改都应该反映到客户端的屏幕上”。我该如何做这种通知服务？

Answer 1

这可能不是您具体问题的答案，但可能有助于评估您是否可以（或应该）在您的应用程序的哪些部分使用 CQRS？

更具体地说：CQRS 既不是无论如何都应该应用的灵丹妙药，也不是整个应用程序的总体架构风格。

CQRS 在应用于单个和明确指定的有界上下文时可以提供许多优势（参见 Eric Evans 的域驱动设计）。

您或您的团队应首先提出的问题：

• 我的应用程序的限界上下文是什么？
• 对于每个 BC：它基本上是 CRUD 还是需要更复杂和复杂的建模？
• 如果它是 CRUD，那么就这样实现它
• 如果它很复杂，那么问题已经解决了吗？是否需要重新发明轮子，或者我们可以只使用一个完成的解决方案（概念上甚至是一个软件）
• 如果我们需要自己构建它，这个特定的 BC 是否提供了主要的业务价值，我们的实施是否提供了竞争优势的潜力？（参考领域驱动设计中的“核心领域”）
• 如果以上适用，那么研究各种架构风格并选择最合适的。

长话短说：不要试图在整个应用程序上强加一种风格。识别 BC，并为每个 BC 使用满足要求的最简单的解决方案。这很可能是 CQRS，但在您的应用程序中最多只有一两个 BC。

将精力集中在应用程序中最复杂的部分，如果使用 CQRS 进行形式化和实施，则可以提供真正的优势。

Answer 2

1. 数据库不同步做事，它们使用根据数据库事务隔离级别规则交错的事务。但他们确实会更新他们的索引作为交易的一部分，这才是最重要的部分。
2. 不，它没有，但它消除了单个写入器阻塞多个读取器的问题，其中您拥有高度竞争的资源，例如数据库表。例如，在我工作的系统中，爆炸数据是从传感器插入的，并且作为为用户创建报告的一部分读取。这是 CQRS 非常适合的位置。CQRS 的大多数实现都控制了它们的并发问题，它实际上是与 DDD 一起的一个很好的模型，其中您的并发是激烈竞争的业务逻辑。但是，您会获得其他属性，例如没有堆栈或不得不因幂等性和消息重新排序而死。
3. 您将有两个数据库；一个保存事件（如果您正在进行事件采购）/实体和另一个/多个其他每个视图，您希望与事件保持同步。
4. 你会想使用像 MassTransit + SignalR 这样的东西。创建一个订阅事件并通过 SignalR-hub 向浏览器推送通知的读取模型（基本上是每个屏幕的 DTO ）。