0

I'm looking at building an application using Play. Imagine a typical eCommerce domain model: Customer, Order, Order Line Item, Product.

In investigating various options for persistence the recommendation seems to be to avoid ORM layers in Scala and use a different abstraction, such as Slick.

Where I am stuck is that with an ORM I could pass a single "Order" object to my view, which could then use existing relationships to pull related information from the Customer, OrderLines, and Products. With Slick, I'm currently passing a tuple of (Order, Customer, Seq[(OrderLine, Product)]) to the view to provide the same information. If you start to complicate the model a bit more, say with an Address on the customer object, it gets very messy quickly.

Is this the recommended approach or am I missing something? I've found several Play-Slick example applications, but they just have 1 or 2 entities, so they don't really address the issue I bring up here.

Dave DeCaprio
  • 2,051
  • 17
  • 31

1 Answers1

0

Have a look at the Slick-Examples, especially: This one If you implemented your classes correctly you should be able to access either Customer-object via the Order-object or vice-versa (for example order.customer.name or something like that to access the customer's Name).

Peanut
  • 3,753
  • 3
  • 31
  • 45
  • That example helps, but the problem is that the Users table doesn't actually map me back to a User object, only a tuple of the fields. object Users extends Table[(String, Int, Option[Int])]("USERS") One potential solution would be to create separate User objects, one which just holds the foreign key, and another that has the actual object. – Dave DeCaprio Oct 28 '13 at 15:54
  • You should introduce case classes for convenient interaction: [Mapped Tables](http://slick.typesafe.com/doc/1.0.1/lifted-embedding.html#mapped-tables). With this you will get a `User` and not a Tuple. Have a look at `foreignKey` as well for your mapping. – Thomas Rawyler Oct 28 '13 at 16:52