Il modello della mia applicazione include un numero di entità che condividono molte proprietà comuni e sono gestite da molte delle stesse classi.
Se usassi un ORM, definirei una classe astratta con le proprietà comuni, l'ereditarietà della tabella delle classi di installazione per la persistenza e le classi che operano su tutti questi tipi di entità operano sulla classe astratta.
Tuttavia, sto usando Slick, non un ORM. Potrei facilmente organizzare una soluzione simile a un ORM:
sealed trait Shape {
def id: Long
def color: String
}
case class Triangle(id: Long, color: String, a: Int, b: Int, c: Int) extends Shape
case class Square(id: Long, color: String, sideLength: Int) extends Shape
//Hides the fact that shape instances are persisted in two tables
class ShapeDAO {
def create(shape: Shape) : Unit
def update(shape: Shape) : Unit
def retrieve(id: Long): Option[Shape]
def delete(id: Long): Unit
}
Perdo la componibilità che è un punto di forza per il slick, ma sembra che potrei essere in grado di recuperarlo aggiungendo qualcosa di così terribile:
def rawShape: Query =
(shapes joinLeft triangles on (shapes.id === triangles.id)
joinLeft squares on (shapes.id === squares.id)) map {
shape_type match {
case "triangle" => Triangle(shape, triangle)
case "square" => Square(shape, square)
}
Potrei quindi unirmi a rawShape o altrimenti usarlo nei casi in cui ho bisogno di maggiore flessibilità.
Quanto è grave ciò che sto suggerendo? Le query complicate che potrebbero trarre vantaggio dall'essere in grado di costruire qualcosa come rawQuery sono molto rare in questa applicazione ... per la maggior parte siamo solo CRUDO di singole entità in modi molto semplici. Avere una classe base comune e un singolo DAO che incapsula tutti i dettagli disordinati di ottenere le forme sarebbe una grande vittoria per il progetto, in quanto manterrebbe le classi che hanno a che fare con le forme semplici.