La creazione di due diversi tipi di utenti (Scala, ascensore)

Question

Io sono la creazione di un sito web, che avrà bisogno di due tipi di utenti: studenti e fornitori. In un ambiente Java tradizionale voglio creare una classe utente (o interfaccia) e quindi creare due classi che ereditate dall'utente. E 'questo il miglior corso in scala troppo, utilizzando il "estende" e "con" modificatori? Se questo è davvero il modo migliore (che ho il sospetto che è), ciò che il modo migliore per mappare questo nel DB? Sarebbe meglio per mantenere una colonna "tipo" e poi lo hanno impostato su uno o l'altro?

La seconda domanda è come lavorare con la vista. Il display sarà molto diversa a seconda del tipo di utente si è e quindi capire ci sarà una certa logica di routing gravi coinvolti o almeno logica incorporata in frammenti nella vista.

Credo che la domanda generale è: C'è un modo "preferito" per andare a fare questo (come una ricetta di rotaie o qualcosa del genere), o sono un po 'fuori da solo

?

Grazie

Answer 1

  

Se questo è davvero il modo migliore (che ho il sospetto che è), ciò che il modo migliore per mappare questo nel DB? Sarebbe meglio per mantenere una colonna "tipo" e poi lo hanno impostato su uno o l'altro?

Non credo che vi sia una chiara "il modo migliore" per progettare la struttura del database, dato uno scenario. La risposta libro di testo è normalizzazione dei database e SECCO .

Tre tavoli avvicinano

Un modo per esempio potrebbe essere quello di creare la tabella utente che contiene entrambi i tipi di utenti, memorizzando solo gli attributi comuni, e creare la tabella degli studenti e la tabella Provider con chiave esterna alla tavola utente e attributi specializzati eventuali. Questo probabilmente non è quello che una persona tradizionale database relazionale lo consiglio, ma le mappe più vicino al modello OO eredità.

Un approccio tabella

Un altro approccio, come hai detto sarebbe quello di creare solo un campo "UserType" e memorizzare entrambi i tipi di utenti nella tabella utente. E 'semplice, ma poi perdete l'occasione di sfruttare l'integrità referenziale del database relazionale. Ad esempio, se si dovesse creare tabella figlio specifico solo per studenti, come ad esempio Compito a casa, non si può semplicemente fare chiave esterna per StudentID se entrambi studenti e fornitori hanno vissuto nella tabella utente.

Due tavoli avvicinano

Se si utilizza quadro object-relational mapping, probabilmente il modo più semplice per andare è quello di mappare esattamente quello che vuoi nell'oggetto stretto mondo nel database, che sarebbe avere studente tavolo e tavolo Provider, ed esprimere la comunanza di due come trait nel lato Scala.

Ho trovato Ascensore cheat sheet :

  

Modelli Definizione

     

ascensore O-R mappato i modelli sono definiti sulla base di una classe con i campi.

class WikiEntry extends KeyedMapper[Long, WikiEntry] {
  def getSingleton = WikiEntry // what's the "meta" object
  def primaryKeyField = id

  // the primary key
  object id extends MappedLongIndex(this)

  // the name of the entry
  object name extends MappedString(this, 32) {
    override def dbIndexed_? = true // indexed in the DB
  }

  object owner extends MappedLongForeignKey(this, User)

  // the text of the entry
  object entry extends MappedTextarea(this, 8192) {
    override def textareaRows  = 10
    override def textareaCols = 50
  }
}

  

Discussione di avere tratti di base condivisi per i modelli .

Nel thread David Pollak scrive:

  

Siete alla ricerca di un po 'di magia Scala:

trait Posting[MyType <: Mapper[MyType]] { // Defines some common fields for posted user content 
  self: MyType => 
  def primaryKeyField = id 
  object id extends MappedLongIndex(this) 
  object creator extends MappedLongForeignKey(this, User) 
  object createdAt extends MappedLong(this) { 
    override def defaultValue = System.currentTimeMillis 
  } 
} 

class FooPosting extends KeyedMapper[FooPosting] with Posting[MyType]