Abstracting Use Case Specific Data Filters or Sorts out

[Dave Schinkel]

I'm trying to find a good pattern or way to abstract out any use case specific filtering for CRUD calls.

If my gateway is what the interactor is using to persist or get data from the database and if it's the gateway ultimately making the calls to the Data Layer Entities that ultimately create the parameterized SQL that's then sent to the DB, even if you keep or build a Data Layer with entities that share as much logic possible to stitch together queries dynamically or whatever, how do you still keep the use case specific filtering, sorting, etc. requests out of the gateway?  

I feel like if I have Use Case A, and it requires to filter data specfic to that use case, then it should be requested in the interactor to the gateway.  How are you abstracting the set of filtering being requested and how are you sending those filter requests to the gateway for CRUD peristence;  how is the gateway receiving those filter requests?  

Just looking for ideas because I don't want my gateway methods coupled to use case filtering logic, stuff like that.

[Sebastian Gozin]

I have no solution.
I just write named queries on the gateway and implement them there.

Stuff like:
- findAllByType(params:[type:'...'], sortings:[[on:'name', orientation:'asc']], subset:[from:0, count:10])
- findAllByNameLikeAndDescriptionLike(params:[name:'...', description:'...'], sortings:[[on:'publicationDateTime', orientation:'desc']], subset:[from:20, count:10])
- findMostRecent(subset:[from:0, count:10])

I guess in the interactors I just test for invocations of those named query methods with the proper arguments.

[Caio Fernando Bertoldi Paes de Andrade]

I do the same as Sebastian. CRUDs are boring. I always try to start with anything else but CRUDs, since the real value of an application is on what it does, not really on what it stores (data storage is the real value of a database, not an application).

Caio

—
Sent from Mailbox

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Dave Schinkel]

Interactors even with CRUDs have behavior.  And even some behavior ends up in gateways.  Filtering is behavior.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.