Hallo,

gibt es hier vielleicht jemanden, der mit diesem Tipp aus der DBIx::Class-FAQ praktische Erfahrungen gemacht hat und daher gute Argumente für oder gegen die Vereinigung zweier Klassen (die eine ein Wrapper der anderen) weiß?

Ich habe zwei Klassen, die eine Moose-basiert, die andere eine DBIx::Class, welche sehr eng zusammenarbeiten. Dazu hat die Mooseklasse ein Member dbicrow, das mit einer DBIx::Class-Instanz verknüpft sein muss, und dazu ein Strauß delegierter Methoden (handles).

Die Moose-Klasse ist eher auf der Ebene der Problemlösung angesiedelt, die DBIC-Klasse eher Storage. Betonung auf eher, es gibt einige Überlappungen und noch mehr Unsicherheit, wo bestimmte Funktionen hingehören. Die Mooseklasse droht mir zu einer Sammlung aller Operationen und Funktionen zu verkommen, die ich nicht im Sinne der DBIx::Class-Konzepte gescheit umzusetzen weiß. Dazu gehört vor allem die Erkennung und Vermeidung von zirkulären Verknüpfungen von Instanzen einer dritten, weiteren DBIC-Klasse, die an eine selbstreferenzielle Tabelle gebunden ist, sowas wie einzelne Knoten gegenüber ganzer Baumstrukturen, die besagte zweite DBIC-Klasse repräsentiert bzw. kapselt. Was das ganze noch komplexer macht: Beziehungen werden nicht nur hierarchisch zwischen Super- und Subnodes konstruiert. Auch Brücken zwischen Knoten verschiedener Hierarchien sind möglich. So ein Gestrüpp kann meiner Einschätzung nach nicht ausschließlich mit DBIx::Class::Relationships beherrscht werden. Schon Copy/Update/Delete-Kaskaden daran zu hindern, dass sie übereinander stolpern – mir schwant arges. Deshalb überlege ich mir jeden Schritt genau, so dass ich mich nicht verheddern möge.

Das auf Basis von DBIx::Class und SQL-Mitteln zu machen, halte ich für ein aussichtsloses Unterfangen. Google schmiss mir zwar einen mehrseitigen MSSQL-Trigger vor die Füße (die von mir benutzte Datenbank ist SQLite3), der zirkuläre Bezüge verhindern helfen soll, aber ... nein, danke.

Dass es also zwei mehr oder weniger getrennte Ebenen geben muss, erscheint mir logisch. Die Frage ist eben das: Soll ich den Zusammenhalt von logik- und verwaltungslastigen moose-basiertem Wrapper auf der einen Seite, und dem rein relationalen DBIx::Class-Datenmodell auf der anderen Seite aufrecht erhalten? Oder rechtzeitg umschwenken auf die vom eingangs verlinkten FAQ-Eintrag vorgeschlagene Lösung, die beiden Ebenen über Vererbung miteinander zu verheiraten?


Viele Grüße,
flowdy
flowdy