3

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

有人告诉我使用 CQRS 模式。

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

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

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

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

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

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

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

4

2 回答 2

2

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

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

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

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

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

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

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

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