Melhores práticas para design de modelo em Ruby on Rails

Question

Os tutoriais do RoR propõem um modelo por tabela para o ORM funcionar.Meu esquema de banco de dados tem cerca de 70 tabelas divididas conceitualmente em 5 grupos de funcionalidade (por exemplo, qualquer tabela vidas em um e apenas um grupo funcional, e as relações entre tabelas de diferentes grupos são minimizadas.) Então:devo projetar um modelo por grupo conceitual ou devo simplesmente ter 70 modelos Rails e deixar o agrupamento 'conceitual'?Obrigado!

Answer 1

Abordo isso em um de meus aplicativos grandes apenas certificando-me de que as tabelas/modelos estejam conceitualmente agrupados por nome (com relacionamento tabela-modelo quase 1:1).Exemplo:

events
event_types
event_groups
event_attendees
etc...

Dessa forma, quando estou usando o TextMate ou qualquer outra coisa, os arquivos do modelo são bem agrupados pela classificação alfa.Tenho 80 modelos neste aplicativo e funciona bem o suficiente para manter as coisas organizadas.

Answer 2

Provavelmente, você deverá ter 70 modelos.Você poderia nomear os modelos para ter 5 namespaces, um para cada grupo, mas isso pode ser mais problemático do que vale a pena.É mais provável que você tenha algumas funcionalidades comuns em cada grupo.Nesse caso, eu criaria um módulo para cada grupo contendo seu comportamento e incluiria isso em cada modelo relevante.Mesmo que não haja funcionalidade compartilhada, isso permitirá que você consulte rapidamente um modelo para seu grupo conceitual.

Answer 3

Definitivamente, você deve usar um modelo por tabela para aproveitar toda a magia do ActiveRecord.

Mas você também pode agrupar seus modelos em namespaces usando módulos e subdiretórios, para evitar ter que gerenciar 70 arquivos em seu diretório de modelos.

Por exemplo, você poderia ter:

app/models/admin/user.rb
app/models/admin/group.rb

para modelos Admin::User e Admin::Group, e

app/models/publishing/article.rb
app/models/publishing/comment.rb

para publicação::artigo e publicação::comentário

E assim por diante...

Answer 4

Sem conhecer mais detalhes sobre a natureza das setenta tabelas e suas relações conceituais não é realmente possível dar uma boa resposta.Essas tabelas são legadas ou você as projetou do zero?

As tabelas estão relacionadas por algum tipo de padrão de herança ou poderiam estar?Rails pode fazer uma forma limitada de herança.Procure Herança de Tabela Única (STI).

Pessoalmente, eu me esforçaria muito para evitar trabalhar com setenta tabelas simplesmente porque isso dá muito trabalho - setenta modelos e controladores e suas mais de 4 visualizações, ajudantes, layouts e testes, sem mencionar o problema de carga de memória de manter o projeto em ind.A menos, é claro, que eu estivesse sendo pago por hora e bem o suficiente para compensar a repetição.

Answer 5

Antes de começar a fazer 70 modelos, considere esta questão para ajudá-lo a decidir:

Cada uma de suas tabelas seria considerada um "objeto", por exemplo, uma tabela "carros", ou algumas das tabelas contêm apenas informações de relacionamento, todas as colunas de chave estrangeira, por exemplo?

No Rails apenas as tabelas de "objetos" se tornam modelos!(Com algumas exceções para tipos específicos de associações) Portanto, é muito provável que, se você tiver apenas 5 grupos de funcionalidades, não tenha 70 modelos.Além disso, se os grupos de funcionalidades mencionados forem muito diferentes, eles poderão até ser mais adequados em seu próprio aplicativo.

Answer 6

Pode haver um pequeno número de casos em que você pode usar o modelo de herança de tabela única padrão do Rails.Talvez todas as classes em um agrupamento funcional específico tenham os mesmos campos (ou quase todos iguais).Nesse caso, aproveite as ofertas do DRYness STI.Porém, quando não fizer sentido, use classe por tabela.

Na versão classe por tabela, você não pode facilmente inserir funcionalidades comuns em uma classe base.Em vez disso, coloque-o em um módulo.Uma hierarquia como a seguinte pode ser útil:

app/models/admin/base.rb - module Admin::Base, included by all other Admin::xxx
app/models/admin/user.rb - class Admin::User, includes Admin::Base
app/models/admin/group.rb - class Admin::Group, includes Admin::Base

Answer 7

Já foi mencionado que é difícil dar conselhos decentes sem conhecer o esquema do seu banco de dados, etc., no entanto, eu preferiria criar mais de 70 modelos (um para cada uma de suas tabelas).

Você pode conseguir abandonar algum modelo, mas pelo custo (insignificante) você também pode tê-los lá.

Você não precisa criar um controlador + visualizações para cada modelo (conforme respondido por srboisvert).Você só precisa de um controlador para cada recurso (que eu esperaria ser muito menor que 70 - provavelmente apenas 10 ou 15, a julgar pela sua descrição).