• 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

Beispiel aus dem Buch 1 Entity = 1 Modul und Beziehungen

gelleneu

New member
Beim Lesen des Buches hat mich ein wenig verwundert, das der Autor pro Business-Logik Entität je ein eigenes Modul mit Model, InputValidator und anderen Daten anlegt.

Dabei entstehen für mich zwei Fragen:

1. Zum einen könnte es leicht eine große Abhängigkeit zwischen diesen Entitätsmodulen geben. Aber ist nicht grad die Unabhängigkeit das Ziel von Modulen?

2. Zum zweiten: wie stellt sich der Autor das Handling mit Relationen zwischen den Entitäten vor?

Ein Beispiel:
Angenommen man hat Bilder und Videos als jeweils eine Entität. Als dritte Entität gibt es Tags. Die Tags liegen in einer eigenen Datenbanktabelle und sind per n:m Relation jeweils mit Videos und Bildern verknüpft. Wenn ich jetzt ein Bild "tagge" dann möchte ich die ins Formular eingegeben Tags beim Speichern der Bild-Informationen gleich mitspeichern. Das gleiche möchte ich beim Video. Also muß ich schon mal dafür sorgen das alle Module vorhanden sind.
Desweiteren müßte ich mir überlegen, wo ich die TableObjekt Klassen für die Verknüpfungstabellen ablege (ins ImageEntity-Modul als Image2TagTable.php oder ins TagEntity-Modul als Tag2Image.php?

Mein Ansatz wäre, dass das TagEntity Modul eine Art "TagSaveListener" bekommt. Dieser lauscht auf diverse Ereignisse ("Video Saved, Image saved") und wird dann aktiv, wenn die Ereignisse eintreten. Letzteres hätte den Vorteil, dass, im Falle des Fehlens des TagEntity Moduls, zwar keine Tags gespeichert würden, aber auch kein systemseitiger Fehler (fehlendes Modul TagEntity) auftritt. Ist dieser Ansatz tauglich?
 

Ralf

New member
Hallo gelleneu,

an sich ist das nicht ganz richtig. Ich verwende im Zend\Expressive und im Zend\Mvc Teil ja verschieden komplexe Model-Layer. Bei der Middleware Anwendung ist die etwas einfacher gehalten ohne Entitäten, aber dort finden sich im Pizza Modul zumindest zwei Repositories, die sowohl einzeln als auch kombiniert verwendet werden können.

https://github.com/zf3buch/vote-my-pizza/tree/chapter_09_01/modules/Pizza/src/Model/Repository

Zu 1. Man muss man den Abhängigkeiten der Module immer darauf aufpassen, wie diese Abhängigkeiten wirken. Es ist kein Problem, wenn Modul A von B abhängig ist. Wenn dann zugleich aber auch Modul B von A abhängig ist, wird es kompliziert. Selbstverständlich kannst du auch mehrere Entitäten in einem Modul vorhalten, solange diese in einem sinnvollen Zusammenhang stehen. So macht es keinen Sinn, in einem Shop, die Bestellung von den Bestellpositionen zu trennen. Ich würde aber nie die Bestellungen und die Produkte, die ja Teil einer Bestellung sind, in demselben Modul vorhalten. Da kommt es immer auf den Einzelfall an. Dass Datenmodell im Buch ist eher einfach gehalten, da der Fokus in erster Linie auf dem Einsatz der ZF3 Komponenten liegt. Ursprünglich wollte ich beim Domain-Layer noch etwas mehr in die Tiefe gehen. Dies konnte ich aus Zeit- und Platzgrünen aber nicht mehr adäquat realisieren.

Zu 2. Bei dem Fall würde ich die Tags tatsächlich in einem eigenen Modul vorhalten, da sie in verschiedenen Modulen (Bilder und Videos) gebraucht werden. Somit sollte die Table und Entity Klasse auch im Tag Modul liegen. Das Laden der Daten könnte dann ein Domain-Service übernehmen, der mit den beiden Entitäten / Repositories für Videos und Tags zusammenarbeiten kann.

Ich hoffe, ich konnte etwas Licht ins Dunkle bringen.

Gruß,

Ralf
 

gelleneu

New member
Hallo Ralf,

vielen Dank für deine Antwort. Im Großen und Ganzen sehe ich das auch so. Am Anfang fand ich den Gedanken, ein Model in ein eigenes Modul zu packen sehr gewöhnungsbedürftig. Aber je mehr man damit arbeitet, desto schöner und sauberer ist das Ganze. Klar sind Produkte und Bestellungen getrennte Module. Bei Preisen wird es schon schwieriger. Zunächst wäre jeder Preis sehr produktspezifisch. Allerdings nimmt die Bedeutung von Preisen (Aktionspreise etc..) sehr stark zu, so daß es auch hier sinnvoll sein könnte die in ein eigenes Modul zu packen. Um ehrlich zu sein habe ich mich mit dem Middleware Ansatz noch nicht so stark beschäftigt. In der Firma wird es erstmal wichtig sein, das bestehende ZF1 Projekt auf ZF3 zu migrieren und der MVC-Ansatz ist im Team noch zu stark "state of the art".

Eine Sache habe ich noch: im Repository wird mittels createAdvertFromData immer ein AdvertModel angelegt, welches per nextId sofort eine gültige ID aus der Datenbank bekommt. Dies begründest du damit, das ein Model nur MIT gültiger ID vollständig ist. warum gibt es dann in der saveAdvert Methode den Ansatz "insertAdvert" aufzurufen, wenn die ID des Models null ist? Nach meinem Verständnis dürfte dies niemals auftreten, da saveAdvert immer nur mit einem Model aufgerufen wird, welches eine gültige ID bereits besitzt. Oder?
 
Zuletzt bearbeitet:

Ralf

New member
Hallo gelleneu,

damit hast du natürlich recht. Eigentlich dürfte es niemals auftreten. Es ist aber als Fallback gedacht, falls jemand eine Annonce speichert, ohne dieses vorher createAdvertFromData() aufgerufen zu haben. Alternativ könnte man an der Stelle auch eine Exception werfen, wenn keine ID gesetzt ist.

Gruß,

Ralf
 

Ralf

New member
Weil das Zusammenspiel mit Zend\Hydrator und Zend\Db nur richtig klappt, wenn man ein AdvertModel auch mit NULL Werten befüllen kann. Ich weiß, dass ist dies nicht optimal ist, aber der Ansatz erhebt auch keinen Anspruch darauf, dass er nicht weiter verbessert werden kann. ;-)

Gruß,

Ralf
 

gelleneu

New member
Okay, jetzt finde ich deine Antwort fast schade, nämlich das es "nur" Fallback sein sollte. Es ist nämlich tatsächlich fast ein philosophischer Ansatz: in deinem Falle würden nämlich die Unterscheidungen in "insertAdvert" und "updateAdvert" im Repository und im Storage entfallen können da es nur noch ein "save" gäbe. Andererseits hat die Variante auch Nachteile, wenn der Speichervorgang nach dem Erstellen der ID unterbrochen bzw. abgebrochen wird...

Na gut, jetzt ist erstmal Weihnachten! Dir und deinen Angehörigen ein frohes Fest und einen guten Rutsch ins Neue Jahr!
 

Ralf

New member
Ja, wie gesagt, ist der Ansatz im Buch sicherlich nicht der Weisheit letzter Schluss. In der Praxis komme ich bei den von mir betreuten Projekten, die diesen Ansatz verfolgen, aber gut zurecht. Deshalb hat er auch seinen Weg ins Buch gefunden. Und wegen der Save Methode, klar ließe sich der Fallback durch das Prüfen des Zustands und das Werfen einer Exception auch umgehen. Aber wie gesagt, Verbesserungspotential hat sicherlich jeder Ansatz.

Dir auch ein Frohes Fest und einen Guten Rutsch ins Jahr 2017!

Gruß,

Ralf
 
Oben