Using Slick with Scala (with Playframwork 2.3)

Question

From a design point of view, and for a medium sized application, is it "alright" to use your Table Objects in your Business Logic Layer? When I say alright, I really mean is it not bad practice to.

There are a lot of software patterns out there such as the repository pattern, active record pattern etc. And I am just not sure if they are suited for a language such as Scala.

Answer 1

To my taste it is even better then repository or active record pattern. With active record you'll have to add magic to the object itself, hard to decouple not very transparent. With repository pattern you'll end up with lots of small repositories, for each entity which are very dumb by itself and all their function is to wrap calls to a database in a decoupled manner, mainly to be able to test on the mock or in-memory db.

But when you use table queries in your service layer ( or Business Logic Layer if you wish) you are not sacrificing testability ( or louse coupling). Database functionality itself is abstracted in the scala.slick.driver.JdbcProfile so you don't need to make another abstraction to factor it out.

Of course it's better to group all queries that are used more than once near the table definition and import them to your services, but that's not exactly a repository, just a bunch of composable queries.

Hope this helps.

Answer 2

It's a legit pattern if you decide to use Slick Table and TableQuery objects directly into your business/service layer. Slick abstracts out low level db code anyways. using Slick API doesn't look much different than using your regular Scala APIs so there shouldn't be a reason to use record, repository or any other traditional patterns when using Slick.

when composing Queries I find it useful to use Query extension implicit classes. you can find some details about this style here and here