Meilleures pratiques pour la conception de modèles en Ruby on Rails

Question

Les tutoriels RoR proposent un modèle par table pour que l'ORM fonctionne. Mon schéma de base de données contient environ 70 tables réparties conceptuellement en 5 groupes de fonctionnalités. (Par exemple, une table donnée vit dans un et un seul groupe fonctionnel et les relations entre les tables de différents groupes sont minimisées.) Donc: devrais-je concevoir un modèle par groupe conceptuel, ou devrais-je simplement avoir 70 modèles Rails et laisser le groupe «conceptuel»? Merci!

Answer 1

Je traite cela dans l'une de mes grandes applications en m'assurant simplement que les tables / modèles sont regroupés conceptuellement par nom (avec une relation modèle / table presque 1: 1). Exemple:

events
event_types
event_groups
event_attendees
etc...

Ainsi, lorsque j'utilise TextMate ou autre, les fichiers de modèle sont bien regroupés par tri alpha. J'ai 80 modèles dans cette application, et ça marche assez bien pour que tout reste organisé.

Answer 2

Très probablement, vous devriez avoir 70 modèles. Vous pouvez créer un espace de noms dans les modèles pour avoir 5 espaces de noms, un pour chaque groupe, mais cela peut poser plus de problèmes. Plus probablement, vous avez des fonctionnalités communes dans chaque groupe. Dans ce cas, je créerais un module pour chaque groupe contenant son comportement et l'inclurais dans chaque modèle pertinent. Même s'il n'y a pas de fonctionnalité partagée, cela peut vous permettre d'interroger rapidement un modèle pour son groupe conceptuel.

Answer 3

Vous devez absolument utiliser un modèle par table afin de tirer parti de toute la magie d'ActiveRecord.

Vous pouvez également regrouper vos modèles dans des espaces de noms à l'aide de modules et de sous-répertoires, afin d'éviter de gérer 70 fichiers dans votre répertoire de modèles.

Par exemple, vous pourriez avoir:

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

pour les modèles Admin :: User et Admin :: Group et

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

for Publishing :: Article et Publishing :: Comment

Et ainsi de suite ...

Answer 4

Sans plus de détails sur la nature des soixante-dix tables et leurs relations conceptuelles, il n’est pas vraiment possible de donner une bonne réponse. S'agit-il de tables héritées ou l'avez-vous conçues à partir de zéro?

Les tables sont-elles liées par un type de modèle d'héritage ou pourraient-elles l'être? Les rails peuvent faire une forme limitée d'héritage. Recherchez l'héritage à table unique (IST).

Personnellement, je ferais beaucoup d’efforts pour éviter de travailler avec soixante-dix tables simplement parce que c’est beaucoup de travail - soixante-dix Modèles & amp; Les contrôleurs et leurs vues 4+, aides, mises en page et tests, sans oublier le problème de charge de mémoire liée au maintien de la conception dans ind. À moins bien sûr que je sois payé à l'heure et suffisamment pour pouvoir compenser la répétition.

Answer 5

Avant de vous lancer dans la fabrication de 70 modèles, veuillez considérer cette question pour vous aider à décider:

Chacune de vos tables serait-elle considérée comme un "objet"? par exemple un " voitures " table ou certaines des tables ne contiennent-elles que des informations de relation, toutes les colonnes de clé étrangère par exemple?

Dans Rails, seul le " objet " les tables deviennent des modèles! (À quelques exceptions près pour des types spécifiques d'associations) Il est donc très probable que si vous n'avez que 5 groupes de fonctionnalités, vous pourriez ne pas avoir 70 modèles. De plus, si les groupes de fonctionnalités que vous avez mentionnés sont très différents, ils pourraient même mieux convenir à leur propre application.

Answer 6

Il peut y avoir un petit nombre de cas dans lesquels vous pouvez utiliser le modèle d'héritage à table unique standard de Rails. Peut-être que toutes les classes d'un groupe fonctionnel particulier ont les mêmes champs (ou presque tous les mêmes). Dans ce cas, profitez des offres DRYness STI. Si cela n’a aucun sens, utilisez classe-par-table.

Dans la version classe par table, vous ne pouvez pas facilement extraire les fonctionnalités communes d'une classe de base. Au lieu de cela, tirez-le dans un module. Une hiérarchie comme celle-ci pourrait s'avérer utile:

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

Cela a déjà été mentionné, il est difficile de donner des conseils avisés sans connaître votre schéma de base de données, etc. Cependant, je m'orienterais plutôt vers la création de plus de 70 modèles (un pour chacune de vos tables).

Vous pouvez peut-être vous en sortir en abandonnant un modèle, mais pour le coût (négligeable), vous pouvez également les avoir ici.

Vous n'avez pas besoin de créer un contrôleur + des vues pour chaque modèle (comme répondu par srboisvert). Vous n’avez besoin que d’un contrôleur pour chaque ressource (ce qui, selon moi, devrait être nettement inférieur à 70, probablement 10 ou 15 environ, à en juger par votre description).