是否有任何良好的API设计模式，其中WRITES与READS分开？

Question

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

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

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

在编写这些类时，我发现自己对WR方法的处理方式与WRITE方法完全不同。

服务类中的READ方法

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

服务类中的WRITE方法

使用WRITE方法，我发现自己正在进行更多的参数检查和业务逻辑实现。实际上在我的服务类中，我依赖于 Rules 类，它只能被我的WRITE方法使用。在READS中也有商业逻辑，但逻辑在WRITES上更严格。

其他参数可能分离READS和WRITES

我也觉得在实现服务类并在类中查找方法时，在我的脑海中首先要知道我是想读取还是写入，然后我会查找该方法。

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

可能的问题，分开是不错的主意？

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

Answer 1

听起来像是指命令查询责任隔离，CQRS

Udi Dahan有一篇很好的文章让你开始here。

MS模式和实践有一个开源项目http://cqrsjourney.github.com/，这是一个很好的例子。

这种模式的缺点是它可能过度工程化，特别是如果你正在编写一个“相对简单的Web应用程序”。

Udi在When to avoid CQRS上写了另一篇文章然后又Why you should be using CQRS almost everywhere希望这会有所帮助。