I have an application that uses Slick 3.2 for data access. Currently the data access layer consists of DAO’s with methods that return the results of queries marshalled into case classes. (So return types like task[Seq[ModelObject]] and so on.)

This setup is nice, because nothing above the DAO layer knows about the table structure — higher level code deals solely with model objects.

However, it leads to some inflexibility. For example, rather than a single filter() method, that allows us to filter on any field, we need a separate find method for every single combination of parameters we might want to search by — findById, findByFoo, findByBar, etc.

I was looking into implementing a generic find() method that would work with model objects. A hypothetical, inelegant example: I could define a type filter with sub-types FilterProperty1, FilterProperty2 and so on, and have the find method transate that into a slick filter for the appropriate database field.

That got me thinking though… it seems like I’m going to a lot of work to hide the table structure from the application. Is the effort really worth it?

If so, is there some standard Slick approach for making the external interface to the persistence layer agnostic with regard to db driver without losing flexibiliy? It seems like for Slick to work in the way it’s intended, I have to use it directly at all levels of the application. (Which would include very high levels of the application knowing about database tabe structure, injecting database driver instances all over the place and so on.)