2

我正在编写一个由三层组成的相对简单的 Web 应用程序：

  1. 前端：非常薄的控制器
  2. 业务逻辑：特定领域的服务
  3. 存储：精简存储库类

如上所述，大部分业务逻辑都在服务层 2 中。

当我编写这些类时，我发现自己对待 READ 方法与 WRITE 方法非常不同。

服务类中的 READ 方法

例如，READ 方法中没有过于严格的参数检查。很多时候，对于简单的读取，Service 方法几乎只用一行代码就实现了 Repository 方法。

服务类中的 WRITE 方法

然而，使用 WRITE 方法，我发现自己做了更多的参数检查和业务逻辑实现。事实上，在我的服务类中，我依赖于一个规则类，它只被我的 WRITE 方法真正使用。READS 中也有 biz 逻辑，但 WRITES 逻辑更严格。

其他可能分离 READS 和 WRITES 的论据

我也觉得在实现一个服务类并在一个类中寻找一个方法的时候，在我的脑海中首先要知道我是想读还是写，然后再去寻找方法。

我也觉得在类中寻找方法时，必须通过以“Create”、“Update”、“Get”、“Retrieve”等开头的任意方法名称来分隔 READS 和 WRITES 似乎很麻烦。

可能的问题，分开是个好主意吗？

我想我正在寻找一种久经考验的模式。我可以尝试自己实现它，但我已经觉得可能存在问题，例如过于复杂的设计，或循环引用，逻辑重复，例如。READ 类可能依赖于 WRITE 类，反之亦然。

4

1 回答 1

5

听起来你指的是命令查询职责分离，CQRS

Udi Dahan 有一篇好文章让您从这里开始。

MS Patterns and practice 有一个开源项目http://cqrsjourney.github.com/这是一个很好的例子。

这种模式的缺点是它可能会过度工程化，尤其是当您正在编写“相对简单的 Web 应用程序”时。

Udi 写了另一篇关于何时避免 CQRS和为什么你应该在几乎所有地方使用 CQRS 的文章希望这会有所帮助。

于 2012-06-03T03:44:50.097 回答