是否有任何好的 API 设计模式将写入与 READS 分开

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

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

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

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

服务类中的读取方法

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

服务类中的写入方法

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

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

我也觉得在实现服务类并在类中寻找方法时，首先在脑海中有一个想法，即我是否要读取或写入，然后我寻找方法。

我也觉得在类中寻找方法时，必须通过以"创建"、"更新"、"获取"、"检索"等开头的任意方法名称分隔 READS 和 WRITE 似乎很混乱。

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

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