Die RoR-Tutorials setzen ein Modell pro Tabelle, damit das ORM funktioniert. Mein DB-Schema hat ungefähr 70 Tabellen, die konzeptionell in 5 Funktionsgruppen unterteilt sind. Also: Soll ich ein Modell entwerfen? Also: Soll ich ein Modell entwerfen? pro konzeptionelle Gruppe, oder soll ich einfach 70 Rails-Modelle haben und die Gruppierung "konzeptionell" lassen? Danke!Best Practice für das Modell-Design in Ruby on Rails
behandle ich dies in einem meiner großen Apps nur dafür sorgen, dass die Tabellen/Modelle konzeptionell nach Name (mit fast 1: 1 Tisch-Modell-Beziehung) gruppiert sind. Beispiel:
events
event_types
event_groups
event_attendees
etc...
So, wenn ich TextMate oder was auch immer verwende, sind die Modelldateien nett gruppiert durch die Alpha-Sortierung. Ich habe 80 Modelle in dieser App, und es funktioniert gut genug, um die Dinge organisiert zu halten.
Höchstwahrscheinlich sollten Sie 70 Modelle haben. Sie könnten die Modelle mit Namespaces versehen, die fünf Namespaces haben, eines für jede Gruppe, aber das kann mehr Probleme verursachen als es wert ist. Wahrscheinlich haben Sie in jeder Gruppe einige gemeinsame Funktionen. In diesem Fall würde ich für jede Gruppe ein Modul erstellen, das ihr Verhalten enthält, und dieses in jedes relevante Modell aufnehmen. Selbst wenn es keine gemeinsam genutzten Funktionen gibt, können Sie so ein Modell für seine konzeptionelle Gruppe schnell abfragen.
Vielen Dank! Plötzlich verstehe ich, warum ich Module verwenden möchte. Aus, um mehr zu lesen .. – NickR
Sie sollten auf jeden Fall ein Modell pro Tabelle verwenden, um alle Vorteile von ActiveRecord zu nutzen.
Sie können Ihre Modelle jedoch auch in Modulen unterteilen, indem Sie Module und Unterverzeichnisse in Namespaces gruppieren, um zu vermeiden, dass Sie 70 Dateien in Ihrem Modellverzeichnis verwalten müssen.
Zum Beispiel könnten Sie haben:
app/models/admin/user.rb
app/models/admin/group.rb
für Modelle Admin :: User und Admin :: Group, und
app/models/publishing/article.rb
app/models/publishing/comment.rb
für Publishing :: Artikel und Verlag :: Kommentar
Und so weiter ...
Danke! Die Unterverzeichnisse/Namespaces sind eine gute Lösung. Nick – NickR
Es kann eine kleine Anzahl von Fällen geben, in denen Sie die Rails standa verwenden können Single-Table-Vererbung Modell. Vielleicht haben alle Klassen in einer bestimmten funktionalen Gruppierung dieselben Felder (oder fast alle gleich). Nutzen Sie in diesem Fall die DRYness STI Angebote. Wenn es jedoch keinen Sinn ergibt, verwenden Sie class-per-table.
In der Klasse-pro-Tabelle-Version können Sie nicht einfach allgemeine Funktionalität in eine Basisklasse ziehen. Ziehen Sie es stattdessen in ein Modul. Eine Hierarchie wie die folgende könnte sich als nützlich erweisen:
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
Ohne weitere Einzelheiten über die Art der siebzig Tabellen und ihre konzeptionellen Beziehungen zu wissen, es ist nicht wirklich möglich ist, eine gute Antwort zu geben. Sind diese Legacy-Tabellen oder haben Sie dies von Grund auf neu gestaltet?
Sind die Tabellen durch eine Art Vererbungsmuster verbunden oder könnten sie? Schienen können eine begrenzte Form der Vererbung machen. Suchen Sie nach Single Table Inheritance (STI).
Persönlich würde ich eine Menge Mühe in die Vermeidung der Arbeit mit siebzig Tabellen, einfach weil das ist eine Menge Arbeit - siebzig Modelle & Controller und ihre 4+ Ansichten, Helfer, Layouts und Tests ganz zu schweigen von dem Speicher laden Problem, das Design in ind zu halten. Außer natürlich, ich wurde stundenweise bezahlt und gut genug, um die Wiederholung auszugleichen.
Es ist bereits erwähnt, es ist schwer, anständige Ratschläge zu geben, ohne Ihr Datenbankschema usw. zu kennen, jedoch würde ich mich auf die Erstellung der über 70 Modelle (eines für jede Ihrer Tabellen) konzentrieren.
)Sie können in der Lage sein, um wegzukommen mit etwas Modell Notwasserung, aber für die Kosten (negliable) Sie als auch sie dort haben.
Sie brauchen keinen Controller + Ansichten für jedes Modell (wie answerd von srboisvert) zu erstellen. Sie brauchen nur einen Controller für jede Ressource (was ich erwarten würde, viel weniger als 70 zu sein - wahrscheinlich nur 10 oder 15 oder so nach Ihrer Beschreibung).
Bevor in einem machen 70 Modelle Springen, beachten Sie bitte diese Frage, um zu entscheiden: jede Ihrer Tabellen
Würde ein „Objekt“ zum Beispiel ein „Autos“ Tisch oder sind nur einige der Tabellen in Betracht gezogen werden Halte nur Beziehungsinformationen, zum Beispiel alle Fremdschlüsselspalten?
In Rails nur die "Objekt" Tabellen werden Modelle! (Mit einigen Ausnahmen für bestimmte Arten von Assoziationen) Es ist also sehr wahrscheinlich, dass Sie, wenn Sie nur 5 Funktionsgruppen haben, nicht über 70 Modelle verfügen. Wenn die von Ihnen erwähnten Funktionsgruppen sehr unterschiedlich sind, sind sie möglicherweise sogar in ihrer eigenen App am besten geeignet.
Natürlich - das löst das Problem ordentlich. Danke! – NickR