turk porno porno escort rokettube
Ergebnis 1 bis 4 von 4

Thema: Best Practice - Data Mapper

  1. #1
    Neuer Benutzer
    Registriert seit
    20.09.2016
    Beiträge
    9
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard Best Practice - Data Mapper

    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

  2. #2
    Super-Moderator Avatar von Kaiuwe
    Registriert seit
    30.12.2006
    Beiträge
    5.520
    Thanks
    4
    Thanked 356 Times in 287 Posts

    Standard

    Ich will mal vorerst nur an einem Punkt einhaken:
    Zitat Zitat von ijisthee Beitrag anzeigen
    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!)
    Zum Zend Framework stehen jedem folgende Quellen zum Nachschlagen zur Verfügung:

  3. #3
    Neuer Benutzer
    Registriert seit
    20.09.2016
    Beiträge
    9
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Zitat Zitat von Kaiuwe Beitrag anzeigen
    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.

    Zitat Zitat von Kaiuwe Beitrag anzeigen
    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.

  4. #4
    Neuer Benutzer
    Registriert seit
    20.09.2016
    Beiträge
    9
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    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

Ähnliche Themen

  1. html5 data in Selectfeld
    Von flod im Forum Formulare
    Antworten: 7
    Letzter Beitrag: 27.12.2011, 16:26
  2. Data Mapper, wann und warum?
    Von Gore im Forum Konzepte & Ideen
    Antworten: 43
    Letzter Beitrag: 04.08.2011, 16:12
  3. Data-push in Zend_AMF
    Von t-lo im Forum Web & Webservices
    Antworten: 1
    Letzter Beitrag: 16.09.2009, 16:53
  4. Model -> Data Mapper -> Daten
    Von ArneRie im Forum Konzepte & Ideen
    Antworten: 9
    Letzter Beitrag: 11.08.2009, 14:37
  5. Dojox.data.Grid
    Von Nilson im Forum Javascript + RIA
    Antworten: 3
    Letzter Beitrag: 02.03.2009, 17:46

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •