Criação de dois tipos diferentes de usuários (Scala, Elevador)

Question

Estou criando um site que vai precisar de dois tipos de usuários: alunos e fornecedores. Em um ambiente java tradicional Gostaria de criar uma classe de usuário (ou interface) e, em seguida, criar duas classes que herdadas do usuário. É este o melhor curso em scala também, usando o "estende" e "com" modificadores? Se isso é realmente a melhor maneira (que eu suspeito que é), qual é a melhor maneira de mapear isso no DB? Seria melhor para manter uma coluna "type" e, em seguida, tê-lo definido como um ou o outro?

A segunda questão é como trabalhar com a vista. A exibição será muito diferente, dependendo do tipo de um utilizador é e assim descobrir que haverá alguma lógica de encaminhamento séria envolvida ou, pelo menos, a lógica construído em fragmentos na vista.

Eu acho que a questão primordial é: Existe uma maneira "preferido" para ir sobre como fazer isso (como uma receita em trilhos ou algo assim), ou sou eu meio que no meu próprio

?

Graças

Answer 1

Se isso é realmente a melhor maneira (que eu suspeito que é), qual é a melhor maneira de mapear isso no DB? Seria melhor para manter uma coluna "type" e, em seguida, tê-lo definido como um ou o outro?

Eu não acho que existe uma clara "a melhor maneira" para projetar a estrutura de banco de dados diante de um cenário. A resposta do livro de texto é banco de dados normalização e DRY .

Três tabelas aproximar

Uma forma, por exemplo, poderia ser a criação de tabela de usuário contendo ambos os tipos de usuários, armazenando apenas os atributos comuns, e criar a tabela Student e mesa Provider com chave estrangeira para a tabela de usuário e atributos especializados se houver. Isso provavelmente não é o que uma pessoa tradicional banco de dados relacional recomendaria, mas ele mapeia mais perto do modelo de herança OO.

Uma abordagem tabela

Outra abordagem como você disse seria apenas para criar um campo "UserType" e armazenar os dois tipos de usuários na tabela de usuários. É simples, mas, em seguida, perder a oportunidade de aproveitar a integridade referencial do banco de dados relacional. Por exemplo, se você fosse criar criança tabela específica apenas para Student, como Homework, você não pode simplesmente fazer chave estrangeira para StudentID se ambos os estudantes e prestadores viveu na tabela do usuário.

Duas mesas aproximar

Se você estiver usando objeto-relacional framework de mapeamento, provavelmente a maneira mais fácil de ir é para mapear exatamente o que você quer no mundo do objeto angústia para o banco de dados, o que seria ter mesa Student e mesa Provider, e expressar a comunhão de dois como característica em lado Scala.

Eu encontrei Elevador Cheat Sheet :

definição de modelos

modelos mapeados elevador O-R são definidos com base em uma classe com campos.

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
  }
}

Discussão sobre ter traços base comum para modelos .

No segmento David Pollak escreve:

Você está procurando um pouco de 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]