Die RoR-Tutorials setzen ein Modell pro Tabelle, damit das ORM funktioniert. Mein DB-Schema enthält etwa 70 Tabellen, die konzeptionell in 5 Funktionsgruppen unterteilt sind (Zum Beispiel lebt jede gegebene Tabelle in einer und nur einer funktionalen Gruppe, und Beziehungen zwischen Tabellen verschiedener Gruppen werden minimiert.) Also: Soll ich ein Modell pro konzeptueller Gruppe entwerfen, oder soll ich einfach 70 Rails-Modelle haben und die Gruppierung "konzeptionell" lassen? Danke!
Ich behandle das in einer meiner großen Apps, indem ich einfach sicherstelle, dass die Tabellen / Modelle konzeptionell nach Namen gruppiert sind (mit einer fast 1: 1-Tabelle-Modell-Beziehung). Beispiel:
%Vor%Wenn ich TextMate oder was auch immer benutze, werden die Modelldateien durch die Alpha-Sortierung gut gruppiert. Ich habe 80 Modelle in dieser App, und es funktioniert gut genug, um die Dinge organisiert zu halten.
Wahrscheinlich 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 genutzte Funktionalität gibt, können Sie dadurch ein Modell für seine konzeptionelle Gruppe schnell abfragen.
Sie sollten auf jeden Fall ein Modell pro Tabelle verwenden, um alle Vorteile von ActiveRecord zu nutzen.
Sie können Ihre Modelle aber auch mithilfe von Modulen und Unterverzeichnissen in Namespaces gruppieren, um zu vermeiden, dass Sie 70 Dateien in Ihrem Modellverzeichnis verwalten müssen.
Sie könnten beispielsweise Folgendes haben:
%Vor%für die Modelle Admin :: User und Admin :: Group und
%Vor%für Publishing :: Artikel und Publishing :: Kommentar
Und so weiter ...
Ohne nähere Einzelheiten über das Wesen der siebzig Tische und ihre begrifflichen Beziehungen zu kennen, ist es nicht wirklich möglich, 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 das sein? Schienen können eine begrenzte Form der Vererbung machen. Suchen Sie nach Single Table Inheritance (STI).
Ich persönlich würde viel Mühe darauf verwenden, die Arbeit mit siebzig Tischen zu vermeiden, weil das eine Menge Arbeit ist - siebzig Models & amp; Controller und ihre 4+ Ansichten, Helfer, Layouts und Tests, ganz zu schweigen von dem Speicherproblem, das Design in ind zu halten. Es sei denn natürlich, ich wurde stundenweise bezahlt und gut genug, um die Wiederholung auszugleichen.
Bevor Sie in 70er Modelle springen, denken Sie bitte an diese Frage, damit Sie sich entscheiden können:
Würde jede Ihrer Tabellen als "Objekt" betrachtet, zum Beispiel eine "Autos" -Tabelle oder sind einige der Tabellen nur Beziehungsinformationen, zB alle Fremdschlüsselspalten?
In Rails werden nur die "Objekt" -Tabellen zu Modellen! (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 genannten Funktionsgruppen sehr unterschiedlich sind, sind sie möglicherweise sogar in ihrer eigenen App am besten geeignet.
Es kann eine kleine Anzahl von Fällen geben, in denen Sie das Rails-Standardtabellenvererbungsmodell verwenden können. 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:
%Vor%Es wurde bereits erwähnt, es ist schwierig, einen anständigen Ratschlag zu geben, ohne Ihr Datenbankschema usw. zu kennen. Ich würde mich jedoch darauf konzentrieren, die über 70 Modelle zu erstellen (eines für jede Ihrer Tabellen).
Sie können vielleicht mit dem Graben eines Modells davonkommen, aber für die Kosten (vernachläßlich) können Sie sie auch dort haben.
Sie müssen keinen Controller + Ansichten für jedes Modell erstellen (wie von srboisvert beantwortet). 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).
Tags und Links ruby ruby-on-rails activerecord