WCF + CQRS +推送通知
我必须设计一个连接到WCF服务的客户端系统，以便在数据库上执行读和写操作，并获得通知。
我被告知要使用CQRS模式。
为了举个例子，客户端将连接到一个服务，以执行像Get List of Products和UpdateProduct等操作。他们还可以做一些事情，比如接受托运和拒绝托运(这可能导致客户之间的竞争，而客户是第一个这样做的客户)。只有一个客户可以“接受”一批货或“拒绝”一批货。
因此，我阅读了一些关于CQRS的内容，并理解它将读与写分离开来(使用命令)。但是，如果我使用CQRS，我不确定有几个主要问题：
- 如果我在WCF服务上使用CQRS模式--我能指望数据库上的synchronously所做的事情吗？我有点困惑，因为我不希望服务是单线程的(以支持未来的可伸缩性)，但是另一方面--如何确保服务上的写操作以正确的顺序执行？甚至是阅读操作？CQRS模式是否保证有序处理？(有人告诉我这里，CQRS模式使用“update”队列来更新请求以进行脱机处理)。
- 使用CQRS是否消除了并发问题？
- 我是否应该在与数据库交互的所有命令处理程序中使用“TransactionScope”？
- 我花了一个多星期的时间试图理解如何为客户端实现通知服务，而没有任何运气。我有一个设计：
“产品服务”将是一个CQRS服务，但我在通知服务方面有问题。客户端可以向产品服务发送一条命令，以便得到关于类别X的产品的通知。此命令将更新数据库中的请求。现在假设通知服务每15分钟轮询一次数据库，并检查哪个用户希望被轮询哪个类别，然后将新产品发送给要求就这些产品类别发出通知的用户。如果用户更改了产品的类别，而其他20个用户已经在通知窗口中看到了该产品，那么现在会发生什么呢？我需要一些方法来检测该产品不再属于该类别，并向他们发送类似于的通知“从您的视图中删除该产品”。这听起来不太像通知。这听起来更像是‘请求数据库表的常量相关视图，并且每个更改都应该反映到客户端的屏幕’。我如何做这种通知服务?？
回答 2
Stack Overflow用户
发布于 2012-04-28 07:14:35
这可能不是您的具体问题的答案，但可能有助于评估您的应用程序中是否、为什么以及在哪些部分可以(或者应该)使用CQRS？
更确切地说，CQRS既不是应该应用的银弹，也不是贯穿整个应用程序的总体架构风格。
如果将CQRS应用于单个和指定良好的有界上下文，CQRS可以提供许多优点(参见Evans的领域驱动设计)。
你或你的团队应该先问一些问题：
- 我的应用程序的有界上下文是什么？
- 对于每一个BC:基本上是CRUD还是需要更复杂和复杂的建模？
- 如果它是CRUD，那么按如下方式实现它
- 如果是复杂的，那么问题已经解决了吗？是否需要重新发明轮子，或者我们是否可以仅仅使用一个已完成的解决方案(概念上，甚至是一段软件)？
- 如果我们需要自己构建它，这个特定的BC是否提供了主要的业务价值，我们的实现是否提供了例如竞争优势的潜力？(参考领域驱动设计中的“核心领域”)
- 如果以上所述适用，那么研究不同的建筑风格，并选择最适合的。
长话短说:不要试图将一种风格强加于整个应用程序。确定BCs，并为每种使用提供最简单的满足需求的解决方案。这很可能是CQRS，但最多只适用于应用程序中的一两个BCs。
将精力集中在应用程序中最复杂的部分上，如果使用CQRS进行形式化和实现，将提供真正的优势。
Stack Overflow用户
发布于 2012-05-03 15:57:45
- 数据库不同步地执行任务，它们使用根据数据库事务隔离级别的规则交织的事务。但作为交易的一部分，他们确实更新了自己的指数，而这正是重要的部分。
- 不，它没有，但它消除了单个编写器阻塞多个阅读器的问题，在这些资源中，您的资源竞争非常激烈，例如数据库表。例如，在我工作的一个系统中，blast数据是从传感器插入的，并且作为为用户创建报告的一部分而读取。这是一个适合CQRS的位置。CQRS的大多数实现都控制了它们的并发问题，实际上，它与DDD一起是一个很好的模型，在DDD中，您的并发是大量竞争的业务逻辑。但是，您可以获得其他属性，比如没有堆栈或必须使用幂等性和消息重新排序来死。
- 您将拥有两个数据库:一个保存事件(如果您正在进行事件源)/entities，另一个/多个其他视图，您希望随时更新事件。
- 您可能希望使用类似于MassTransit + SignalR的东西。创建一个读取模型(基本上是每个屏幕的DTO )，该模型订阅事件并通过SignalR将通知推送到浏览器。
https://stackoverflow.com/questions/10350514
复制相似问题
腾讯云开发者
