Questions tagged «command-pattern»

两种设计模式都封装了一种算法，并将实现细节与调用类分离。我可以辨别的唯一区别是，策略模式采用了执行参数，而命令模式则没有。 在我看来，命令模式需要所有信息才能在创建时可用，并且能够延迟其调用（也许是脚本的一部分）。 哪些决定指导使用一种模式还是另一种模式？

121 design-patterns  encapsulation  strategy-pattern  command-pattern 

抱歉，找不到答案，我几乎可以肯定有人提出过这个问题。 我的问题是我正在编写一些系统库来运行嵌入式设备。我有可以通过无线电广播发送到这些设备的命令。这只能通过文本来完成。在系统库中，我有一个线程来处理看起来像这样的命令 if (value.equals("A")) { doCommandA() } else if (value.equals("B")) { doCommandB() } else if etc. 问题在于，要执行的命令很多，很快就会变成无法控制的事情。几个月后，看起来很恐怖，调试起来很痛苦，难以理解。

101 java  design-patterns  command-pattern 

我一直在寻找很多时间来找到典型存储库模式（不断增长的专用查询方法列表等）所提出的问题的好的解决方案。请参阅：http : //ayende.com/blog/3955/repository-是新单人）。 我真的很喜欢使用Command查询的想法，特别是通过使用Specification模式。但是，我的规范问题是它仅涉及简单选择的标准（基本上是where子句），而没有处理其他查询问题，例如联接，分组，子集选择或投影等。基本上，许多查询必须经过所有额外的步骤才能获得正确的数据集。 （请注意：我在“命令”模式中使用“命令”一词，也称为查询对象。我并不是在谈论命令/查询分离，而是在查询和命令之间进行区分（更新，删除，插）） 因此，我正在寻找替代方案来封装整个查询，但仍具有足够的灵活性，以至于您不只是将意粉存储库换成大量的命令类。 我曾经使用过例如Linqspecs，虽然我发现能够为选择条件分配有意义的名称具有一定的价值，但这还远远不够。也许我正在寻找一种结合了多种方法的混合解决方案。 我正在寻找别人可能已开发出的解决方案，以解决此问题或解决其他问题，但仍满足这些要求。在链接的文章中，Ayende建议直接使用nHibernate上下文，但我认为这会使您的业务层大大复杂化，因为它现在还必须包含查询信息。 等待期过后，我将为此提供赏金。因此，请为您的解决方案提供值得的奖励，并提供良好的解释，我将选择最佳的解决方案，并支持亚军。 注意：我正在寻找基于ORM的东西。不必显式使用EF或nHibernate，但是它们是最常见的，并且最适合。如果它可以很容易地适应其他ORM，那将是一个好处。Linq兼容也很好。 更新：我真的很惊讶这里没有很多好的建议。似乎人们要么完全是CQRS，要么完全处于存储库阵营中。我的大多数应用程序都不够复杂，不足以保证CQRS（大多数CQRS倡导者很容易地说，您不应将其用于此）。 更新：这里似乎有些混乱。我不是在寻找新的数据访问技术，而是在业务和数据之间设计合理的接口。 理想情况下，我正在寻找的是查询对象，规范模式和存储库之间的某种交叉。就像我在上面说的那样，规范模式仅处理where子句方面，而不处理查询的其他方面，例如联接，子选择等。存储库处理整个查询，但过一会儿就会失去控制。查询对象还处理整个查询，但是我不想简单地用大量的查询对象代替存储库。

90 c#  repository-pattern  command-pattern  specification-pattern 

策略模式和命令模式有什么区别？我也在寻找Java中的一些示例。

77 java  design-patterns  strategy-pattern  command-pattern 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 2年前关闭。 改善这个问题 关于命令是否应该具有返回值，似乎存在无尽的困惑。我想知道是否只是因为参与者没有说明他们的背景或情况而引起的困惑。 混乱 这是混乱的例子... 乌迪·达汉（Udi Dahan）说，命令“没有将错误返回给客户端”，但在同一篇文章中，他展示了一个图，其中命令的确向客户端返回了错误。 Microsoft Press Store上的一篇文章指出“命令...不返回响应”，但随后给出了模糊的警告： 随着围绕CQRS的战场经验的增长，一些实践逐渐巩固并趋于成为最佳实践。在某种程度上与我们刚才所说的相反...今天普遍认为，命令处理程序和应用程序都需要知道事务操作的进行方式。结果必须是已知的... 吉米·博加德（Jimmy Bogard）说“命令总是有结果”，但随后又花了很多功夫来说明命令如何返回无效。 那么，命令处理程序是否返回值？ 答案？ 从吉米·博加德（Jimmy Bogard）的“ CQRS神话”中获取线索，我认为该问题的答案取决于您在说什么程序化/上下文“象限”： +-------------+-------------------------+-----------------+ | | Real-time, Synchronous | Queued, Async | +-------------+-------------------------+-----------------+ | Acceptance | Exception/return-value* | <see below> | | Fulfillment | return-value | n/a | +-------------+-------------------------+-----------------+ 验收（例如验证） 命令“接受”主要是指验证。假定验证结果必须同步地提供给调用方，而不管命令“完成”是同步的还是排队的。 但是，似乎许多从业者并不从命令处理程序中启动验证。从我所看到的，这是因为（1）他们已经找到了一种在应用程序层处理验证的绝佳方法（即，通过数据注释检查有效状态的ASP.NET MVC控制器）或（2）一种体系结构假设命令已提交到（进程外）总线或队列中。后一种异步形式通常不提供同步验证语义或接口。 …

76 design-patterns  architecture  cqrs  command-pattern