2010-11-25 13 views
0

Nun, das ist eine seltsame Anforderung, und ich denke darüber nach, ob dies möglich ist oder nicht. Zweiter Gedanke ist, ob es eine machbare Designentscheidung ist oder nicht. HierEin Grails-App-Domain-Plugin unter mehreren Grails teilen Anwendungsclients und sing Teilmenge von Domain-Klassen

ist das Szenario:

Wir haben eine Datenbank von rund 160 Tischen. Wir haben ein Grails ORM-Plugin oben auf der alten Datenbank erstellt.

Jetzt haben wir verschiedene Anwendungen (Plugins), die dieses Orm-Plugin verwenden werden.

Jede Anwendung kann eigenständig und in Kombination mit anderen Anwendungen ausgeführt werden.

Jede Anwendung verwendet hauptsächlich eine Teilmenge des vollständigen ORM-Modells, das im Plugin entworfen wurde.

Um eine App eigenständig auszuführen, möchte ich nur eine eigenständige Datenbank erstellen, die Tabellen enthält, die von der Anwendung und nicht der gesamten Datenbank mit 160 Tabellen benötigt werden. Aber da eine eigenständige Anwendung eine Abhängigkeit vom oben definierten ORM-Plugin hat, ist es möglich oder nicht, nur eine Teilmenge von Tabellen zu haben oder ich muss ein komplettes Datenbankschema erstellen?

Lassen Sie mich wissen, wenn weitere Details erforderlich sind, um die Frage zu verstehen.

Danke, Alam Sher

Antwort

0

Sie könnten die ORM-zugeordneten Domänenklassen im Ordner src/groovy deklarieren und somit nichts im Plugin abbilden und dann die erforderlichen Klassen in den Endanwendungen erweitern. Die in src deklarierten Zuordnungen werden verwendet.

Dies fügt zusätzliche Komplexität hinzu, aber macht die Sache.

+0

Können Sie mir bitte ein Beispiel oder einen Link zeigen, wo es gemacht wurde? Dies scheint jedoch interessant zu sein. –

+0

Was meinen Sie mit ORM-zugeordneten Domänenklassen in src/groovy? Du meinst, ich entwerfe einfach einen groovigen Objektbaum, der meinem Domänenstrukturbaum entspricht? und wenn ich dann dieses Plugin zu einem Projekt hinzufüge, erweitere ich jede solche Klasse von einem Domänenobjekt und definiere Einschränkungen? Ist es das, was du gesagt hast, oder ich bin total disconnect? –

+0

Ja genau. Entschuldigung - Englisch ist nicht meine Muttersprache. Und Sie müssen Constraints nicht neu definieren (obwohl Sie können), sie sind auch "geerbt". I.e. Wenn 'Klasse B A 'erweitert, ruft Grails B.constraints() auf und ruft somit die statische Eigenschaft von A auf. –

0

Ich würde Splitting schlägt die ORM-Plugin in separaten "sub-orm" Plugins auf. Diese "Sub-Orm" -Plugins könnten natürlich von anderen "Sub-Orm" -Plugins abhängen. Die Trennlinien zwischen den "sub-orm" -Plugins sollten IMHO von der Geschäftsdomäne definiert werden.

Jede "partielle" Anwendung kann dann eine Abhängigkeit von den erforderlichen "sub-orm" Plugins haben, die nur in ihrem Umfang notwendig sind. Die transitive Abhängigkeitsauflösung ist in diesem Fall wertvoll.

Wenn mehrere verschiedene Anwendungen gleichzeitig auf dieselbe Datenbank zugreifen, besteht die Gefahr, dass Sperren von Ausnahmen von Hibernate ausgelöst werden.

+0

Der Bedarf an Tabellen für Zielanwendungen kann variieren, daher muss das entsprechende Sub-Plugin für jede Unteranwendung geändert werden. Abhängigkeiten von Sub-Plugins ändern sich ebenfalls unvorhersehbar. Und gegeben Grails nutzt optimistische Sperrung, wird nicht Concurrency Konflikte von normalen Grails Einrichtungen behandelt werden? –

Verwandte Themen