Let's say you're designing a service that exposes a getByQuery() interface. The client is responsible for composing a query and interpreting the result set returned.
Interesting question to consider: if a query results in an empty record set, is it because the query is valid but no matching records are found, or that the query is invalid in that particular context?
The designer of the service can choose to be helpful and indicate error conditions to distinguish the two cases, but at a cost of having to be more aware of the calling application's context.
Alternatively, the service could be context-agnostic and just return an empty record set. It then would be up to the client to have a complete enough suite of unit tests to have an assertion fail and indicate an error in such a case.
I personally lean towards the services being more agnostic of client context and not getting encumbered by context-specific helper methods too early in their lifecycle. YMMV.
Interesting question to consider: if a query results in an empty record set, is it because the query is valid but no matching records are found, or that the query is invalid in that particular context?
The designer of the service can choose to be helpful and indicate error conditions to distinguish the two cases, but at a cost of having to be more aware of the calling application's context.
Alternatively, the service could be context-agnostic and just return an empty record set. It then would be up to the client to have a complete enough suite of unit tests to have an assertion fail and indicate an error in such a case.
I personally lean towards the services being more agnostic of client context and not getting encumbered by context-specific helper methods too early in their lifecycle. YMMV.
