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

Question

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

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

如上所述,大多数业务逻辑位于服务层2中.

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

READ类Service中的方法

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

服务类中的WRITE方法

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

可能分离READS和WRITES的其他参数

我也觉得在实现服务类并在类中查找方法时,在我的脑海中首先要知道我是否想要READ或WRITE,然后我寻找方法.

我也觉得在类中查找方法时,必须通过以"创建","更新","获取","检索"等等开头的任意方法名称来分隔READS和WRITES.

可能出现问题,分开是个好主意吗？

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

Answer 1

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

乌迪大汉有一个很好的文章,开始你关在这里.

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

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

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