谁应该处理复杂查询，数据映射器或服务层中的条件？

Question

这个问题在消除我的困惑方面做得很好，但是我很难找到关于服务层的确切限制应有的可靠信息来源。对于此示例，假设我们正在处理书籍，并且我们希望按作者获取书籍。本BookDataMapper可以有一个通用的get()接受条件（S），如书的唯一标识符，作者姓名等这个实现是相当微不足道的（逻辑）方法，但如果我们希望有需要更复杂的查询多个条件是什么？假设我们要让某个作者在特定出版商下撰写的所有书籍。我们可以扩展该BookDataMapper->get()方法以解析多个条件，或者可以编写一个新方法，例如BookDataMapper->getByAuthorAndPublisher()。是让服务层直接调用这些[更特定的]方法，还是在BookDataMapper->get()通过多个条件调用更通用的方法之前对条件进行解析？在后一种情况下，服务层将执行更多的逻辑“繁重工作”，从而使数据映射器相当简单。前一种选择将服务层几乎全部缩减为一个中间人，而在诸如的方法中将条件逻辑留给了数据映射器BookDataMapper->getByAuthorAndPublisher()。让服务层解析条件的显而易见的担忧是，某些域逻辑从数据映射器中泄漏出来。（这在此处的链接问题中进行了解释。但是，如果服务层要处理条件，则逻辑不会使它超出模型层；$book_service->getByAuthorAndPublisher()无论如何，控制器都会调用。

Answer 1

我不是学术开发人员，也不知道背后是否有记录在案的最佳实践。当我担任某个层次的消费者（例如，数据映射器）的角色时，我希望拥有一个简洁明了的界面，这实际上是具体的。没有通过或多或少的动态值或参数对象隐藏的合同。我的意思是，否则，如果需要更大的灵活性，我可以直接执行一些SQL。但这会破坏该层。所以画一条线，并与它很好。