• Jeder User im Forum verpflichtet sich zur Akzeptanz und zur Einhaltung dieser Regeln:
    1. Umgangston
      Ein angemessener höflicher Umgangston, ohne Beleidigungen, Beschimpfungen und aggressive Postings ist für jedes Mitglied Pflicht.
    2. Beiträge
      Jedes Mitglied sollte sich bemühen nur sinnvolle Beiträge zum Thema zu posten. Dabei ist unbedingt vorher zu prüfen, ob das Thema vorher schon einmal diskutiert wurde und daher fortgesetzt werden kann
      • Suchfunktion benutzen!
      • offizielle Doku lesen!
    3. Haftung
      Jeder Beitragsersteller übernimmt die alleinige Verantwortung seiner Inhalte.
    4. Werbung
      Wir erlauben keine Beiträge, Signaturen, Private Nachrichten oder eMails an Benutzer, die Werbung enthalten. Ausgenommen
      sind Stellengesuche /-angebote, welche ausschließlich im Forum "Stellengesuche" veröffentlicht werden dürfen.
    5. Verstöße
      Regelwidrige Beiträge sollten dem Team gemeldet werden. Nach deren Überprüfung werden wir schnellstmöglich
      entsprechend handeln.
    6. Authorität
      Den Anweisungen der Team-Mitglieder (Administratoren und Moderatoren) sind in diesem Forum Folge zu leisten.
      Bei Fragen oder Beschwerden bitte an diese wenden.
    Wir möchten Euch darauf aufmerksam machen, dass es bei Verstößen gegen einen oder mehreren der oben genannten
    Punkte dem Team frei steht entsprechend zu handeln. Dies kann z.B. das Löschen eines Beitrags, das Ausschliessen bzw.
    Sperren von Mitgliedern oder aber lediglich eine Verwarnung sein.

    In diesem Zusammenhang sollte erwähnt werden, dass das Forum automatisch die IP-Adresse jedes Beitrag-Erstellers
    speichert. Bei schweren Vergehen, behalten wir es uns vor, die IP-Adresse zur Strafverfolgung weiterzugeben.
  • Willkommen im Zend Framework Forum

    ZF1 Zend Framework 1 + ZF2 Zend Framework 2

    Das Zend Framework Forum ist seit 2006 die erste Anlaufstelle für Zend Framework Entwickler in Deutschland. Mit über 70.000 Beiträgen und einer steigenden Nutzerzahl bietet das Forum hilfreiche Themen und ZF-Tutorials für professionelle Entwickler, fortgeschrittene Programmierer sowie Zend Framework Einsteiger.
    Wenn dies Dein erster Besuch in der Zend Framework Community ist, lies bitte zuerst die Hilfe - FAQ durch. Du musst Dich registrieren, bevor Du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um die Registrierung zu starten. Du kannst auch jetzt schon Beiträge lesen. Hier im Forum findest Du die Zend Framework Hilfe, die Du suchst!

    Grüße an alle Zend Framework Entwickler. Das Team vom Zend Framework Forum!

    Drupal Agentur

Best Practice - Data Mapper

ijisthee

New member
Liebe Community,

ich nutze aktuell einen Data Mapper wie er im Blog Tutorial benutzt wurde.

Nun habe ich, da dort ja die Post-Klasse als Prototype verwendet wurde, auch weiter gemacht.
Allerdings habe ich die Informationen, wie meine Objekte in Relation zueinander stehen in den Mapper gebaut, was mir nun ein wenig auf die Füße fällt.

Nun gibt es ja Standardmethoden wie
- find(id)
- findAll()
- save()
- delete()

Neben diesen Methoden habe ich nun noch eine ganze Reihe Hilfsmethoden, die aber teilweise Businesslogik beinhalten.

Meine Fragen sind nun:

Sollte ich Joins vom Service aus an den Mapper übergeben?
- Damit hätte ich nur einen Mapper mit Basismethoden.

Oder sollte ich für jeden Zweck einen eigenen Mapper schreiben?
- Dann hätte ich allerdings Basismethoden doppelt.

Dritte möglichkeit wäre, ich schreibe einen Abstract Mapper, der die Basismethoden beinhaltet und Concrete Mappers um die einzelnen Bereiche der Anwendungen abzudecken.
- Das klingt für mich erstmal sinnvoll

Ich danke für eure Denkanstöße und konstruktive Kritik.

Liebe Grüße,
Christian
 

Kaiuwe

Super-Moderator
Ich will mal vorerst nur an einem Punkt einhaken:
Sollte ich Joins vom Service aus an den Mapper übergeben?
Das passt nicht ins Konzept, denn dein Service soll gar nicht wissen, wo und wie gespeichert wird. Damit kann ein „Join“ oder ein „fopen“ nicht im Service auftauchen.
Die strikte Trennung erfolgt, damit der Datenspeicher jederzeit ausgetauscht werden kann. Des wegen hast du auch ein „Interface“ für den Mapper definiert. (Das Testen wird natürlich damit auch einfacher.)


Mir fällt aber gerade auf, dass du mit einer alten Version des Tutorials arbeitest! Hat dies einen bestimmten Hintergrund oder hast du dies gar nicht gewusst?

Hier findest du die aktuellen Versionen der Tutorials: https://docs.zendframework.com/tutorials/
(Siehe auch bei der alten Version oben im gelben Kasten, denn dort findest du genau diesen Hinweis!)
 

ijisthee

New member
Mir fällt aber gerade auf, dass du mit einer alten Version des Tutorials arbeitest! Hat dies einen bestimmten Hintergrund oder hast du dies gar nicht gewusst?
Tatsächlich habe ich das nicht gewusst.

Das passt nicht ins Konzept, denn dein Service soll gar nicht wissen, wo und wie gespeichert wird. Damit kann ein „Join“ oder ein „fopen“ nicht im Service auftauchen.
Die strikte Trennung erfolgt, damit der Datenspeicher jederzeit ausgetauscht werden kann. Des wegen hast du auch ein „Interface“ für den Mapper definiert. (Das Testen wird natürlich damit auch einfacher.)
Die Joins vom Service aus an den Mapper übergeben halte ich ebenfalls für sinnfrei aber ich wollte zumindest mal darüber nachdenken, schon allein der Kritik wegen. :)

Du hast meine eigentliche Frage "noch" nicht beantwortet.
Ich glaube aber, ich werde mir den Aufwand machen müssen, einen Mapper und Service für jeden Zweck zu schreiben, sodass das Spektrum der Aufgaben je Service und Mapper so gering wie möglich bleibt.
 

ijisthee

New member
Hallo Kaiuwe,

ich habe heute den ganzen Tag sehr viel gelesen und glaube nun das Prinzip des Data Mappers verstanden zu haben.
Im Grunde stellt er CRUD Operationen zur Verfügung und erstellt Objekte.

Nun bin ich als Entwickler ja grundsätzlich sehr faul und möchte mir Zeit und spätere Änderungen sparen.

Meine Datenbank hat 22 Tabellen.
Sollte ich für jede Tabelle einen Mapper erstellen wie es beim TableGateway Pattern der Fall ist?

Mein Konstrukt, das kennst du vielleicht aus meinen gestrigen Posts besteht ja aus 5 Dimensionen.
Ich werde mal etwas konkreter.

Ich entwickle ein Qualitätsmonitoring System, indem Kontakte zwischen Kunde und Mitarbeiter ausgewertet werden.
Dazu gibt es pro Monitoring eine ganze Reihe von Metadaten.
Zum Teil sind es einfach nur Texte wie eine Kundennummer (es gibt kein CRM dahinter).
Teilweise liegen aber auch weitere Objete dahinter wie Mitarbeiter, Teams, Dienstleister.

So ein Monitoring ist in verschiedene Sektionen aufgebaut.
Insgesamt gibt es zum Beispiel 5 Hauptsektionen, die jede für sich in weitere 3 Untersektionen Ebenen aufgesplittet ist.

Insgesamt muss ich für ein Monitoring Objekt also grob über den Daumen gepeilt 140 Objekte aus 22 Tabellen anlegen.
Aktuell habe ich nur einen Mapper, der aber total chaotisch und schlecht wartbar ist.
Das fällt mir nun auf die Füße und ich möchte aufräumen und es dieses mal "RICHTIG" machen.

Nun lese ich schon seit 2 Tagen wie man es richtig macht, aber es gibt immer wieder die Antwort: Kommt drauf an.

Deshalb nun ein paar Fragen ob "man" es so machen sollte oder eben nicht.

1. Sollte ich von einem Service aus ein zu befüllendes Objekt oder Prototype an den Mapper übergeben, der mir dann Klone erzeugt (z.b. FindAllByMonitoringId()) oder nur ein Objekt hydriert (findbyId())?
  • Überlegungen:
    • Ich kann von außen sagen, welche Tabelle angesteuert werden soll
    • Ich kann einen Mapper für mehrere gleiche Objekte benutzen, da der ClassMethodsHydrator ja die Spalten des Datensatzes der Datenbank an die Setter Methoden des Objektes schickt
    • Wenn sich ein Objekt in seiner Struktur ändert, brauche ich nur das Model und die Datenbanktabelle anpassen
2. Die Models wissen nur, dass sie KindObjekte haben werden. Welche das sind, hängt von der Konfiguration in der Datenbank ab. Das heißt, jede Ebene weiß nur, dass es eine Ebene über sich und eine unter sich hat. Es muss also von Außen gesteuert werden, wie das ganze zusammengesetzt wird.
Mache ich das besser im Service, der dann einfach nur per findById/findAllById die Abfrage an den Mapper sendet oder sollte ich diese Sache dem Model überlassen, welches ja aktuell nur als Container für die Daten mit ein wenig Businesslogik dient?
  • Überlegungen
    • Das Model sollte unabhängig von Abhängigkeiten sein, da die Abhängigkeiten besser von außen verändert werden können sollen
    • Ich müsste, wenn ich es im Model mache, dem Model den Mapper mitteilen, was ja gegen das Pattern des Data Mappers spricht
3. Wenn ich pro Tabelle einen Mapper benötige, sollte ich dann auch einen Service pro Mapper haben?
  • Überlegungen:
    • Ich müsste dann die Geschäftslogik in den Controller oder die Models verlagern
    • Letztes wird ja oft propagiert, aber ich hätte lieber alles an einem Ort, was dafür spricht, einen Service mit mehreren Mappern auszustatten
Ziel ist es, dass wenn ich zum Beispiel 1000 Monitorings abrufe und alle dazugehörigen Objekte, dass ich trotzdem performant bleibe und wenn ich also dann ca. 140.000 Abfragen machen muss, die zwar alle winzig sind, geht das System bestimmt wieder in die Knie.


Die Struktur sieht, falls es hilft, ungefähr so aus:
Monitoring
-metainformation1
-metainformation2
-metainformation3
...
-metainformation15
-Kinder (ca. 70 Objekte in 4 Ebenen)


Ich danke für deine Denkanstöße, die bisher immer sehr geholfen haben. :)

Liebe Grüße,
Christian
 
Oben