porno porno izle rokettube
Seite 1 von 2 1 2 LetzteLetzte
Ergebnis 1 bis 20 von 25

Thema: Unit of Work Pattern in PHP implementieren

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

    Standard Unit of Work Pattern in PHP implementieren

    Hallo,

    zur Zeit lese ich das Buch "Patterns für Enterprise Application Architekturen". Dort wird das Unit of Work Pattern beschrieben, welches die im Rahmen einer Geschäftstransaktion veränderten Objekte sammelt und am Ende der Geschäftstransaktion in einem Rutsch in die Datenbank schreibt. Nebenbei wird auch das Problem der Nebenläufigkeit gelöst.

    Wie kann man dieses Pattern am besten mit PHP implementieren? Im Normalfall weiss Sitzung A ja nichts von den in Sitzung B angeforderten bzw. geänderten Objekten (sitzungsübergreifender Zugriff auf die "Unit of Work" ist ja nicht so einfach möglich). Weiterhin wird im Buch darauf hingewiesen, dass nur ein Thread auf die "Unit of Work" zugreifen darf. Inwiefern ist sowas für PHP relevant?

    Vielen Dank für ein paar Antworten

  2. #2
    Erfahrener Benutzer Avatar von Blackflash
    Registriert seit
    18.02.2007
    Beiträge
    399
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Auch wenn PHP nicht multithreaded ist, kann man die einzelnen Requests als einzelne Threads ansehen. Also müsste jeder Benutzer eine eigene Unit of Work besitzen, damit man sicherstellen kann, dass es nicht zu Konflikten kommt. Du musst dann allerdings Locks einbauen, damit dieselben Daten nicht von mehreren Leuten geändert werden können. Die Umsetzung ist auf jeden Fall nicht mehr trivial.

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

    Standard

    Erstmal Danke für die Antwort.Nun zum Thema

    Das würde bedeuten, dass ich die Informationen der Unit of Work in einer Tabelle ablegen muss auf die dann max. ein User/Request exklusiv zugreifen kann, oder? Gibt es keine andere Möglichkeiten um
    a) Daten sitzungsübergreifend abzulegen (Sitzung A kann die von Sitzung B gemachten Einträge auf der Unit of Work sehen)
    b) sicherzustellen, dass beim Zugriff auf die Unit of Work keine Inkonsistenzen entstehen

    Wenn es nur mit exklusiven Zugriff (Lock) auf die DB funktionert -> hat jemand einen Tipp / Schlagwort wo man Informationen dazu findet? Und baut man sich dann damit nicht einen Flaschenhals ein?

    Danke

  4. #4
    Erfahrener Benutzer
    Registriert seit
    10.09.2007
    Ort
    Wuppertal
    Beiträge
    5.725
    Thanks
    1
    Thanked 41 Times in 40 Posts

    Standard

    Ich würde vielleicht die während der Sitzung benötigten Objekte serialisieren und in die DB schreiben. Als Key würde sich die Session ID eignen, da diese ja unique ist. Eine Idee, wie man diese Objekte von Sitzung A nach B bringt habe ich nicht. Höchstens wenn Sitzung A & B immer vom gleichen User sind, dann kannst du die Objekte auch pro User wegschreiben anhand der UserID.

  5. #5
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Die "Unit of Work" sieht doch explizit vor, dass sie die Objekte etc sammelt während eines Geschäftsprozesses. Aus Sicht des Webservers ist aber mit Abschicken eines Response der Geschäftsprozess beendet. Wieso sollte man dann also die Unit-of-Work und die dort befindlichen Objekte sitzungsübergreifend und persistent erhalten? Zumal es meines Erachtens paradox ist, wenn man Sachen in die Datenbank schreibt, damit diese nicht ständig in die Datenbank schreiben müssen

    a) Daten sitzungsübergreifend abzulegen (Sitzung A kann die von Sitzung B gemachten Einträge auf der Unit of Work sehen)
    Warum sollte man das wollen?

  6. #6
    Neuer Benutzer
    Registriert seit
    25.10.2007
    Beiträge
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Die "Unit of Work" sieht doch explizit vor, dass sie die Objekte etc sammelt während eines Geschäftsprozesses. Aus Sicht des Webservers ist aber mit Abschicken eines Response der Geschäftsprozess beendet. Wieso sollte man dann also die Unit-of-Work und die dort befindlichen Objekte sitzungsübergreifend und persistent erhalten?
    Im Buch wird erwähnt, dass Unit of Work auch die Nebenläufigkeit steuern soll. D.h. doch, dass wenn User A ändernd auf Ressource A zugreift ein User B bspw. nicht mehr auf Ressource A zugreifen darf, oder? Um das zu realiseren muss User B doch sehen können was User A gerade bearbeitet. Vielleicht bin ich aber auch voll auf dem Holzweg.

    Zumal es meines Erachtens paradox ist, wenn man Sachen in die Datenbank schreibt, damit diese nicht ständig in die Datenbank schreiben müssen
    Genau das denk ich mir doch auch Aber eine andere Möglichkeit gibt es ja scheinbar nicht um das Pattern umzusetzen. Oder kann man auf dem PHP Server noch irgendwie etwas dauerhaft im Speicher halten auf das alle Sitzungen Zugriff haben?

  7. #7
    Erfahrener Benutzer
    Registriert seit
    10.09.2007
    Ort
    Wuppertal
    Beiträge
    5.725
    Thanks
    1
    Thanked 41 Times in 40 Posts

    Standard

    Du kannst soetwas auch in die Session schreiben, aber das kann ganz schön den File-Interpreter belasten bei vielen gleichzeitigen Zugriffen oder großen Session-Dateien und damit sich Negativ auf die Response-Zeit des Servers auswirken.

    @DB: Es ist doch ein Unterschied, die Objekte mit einem Request wieder herzustellen anstatt diese neu zu erstellen mit X Requests? Also ich finde das macht schon Sinn!

    @benjamin: User B kann das ja auch sehen, wenn die Daten im Backend geändert wurden. Du kannst ja die Datenhaltung nicht nur über persistente Objekte machen. Solch User-Übergreifende Darstellungen erfordern nur ein gutes Konzept, wie die Änderungen präsentiert werden (z.B. pro "Gruppe" ein logfile, welche gelesen wird und jeder User sieht die Änderung - könnte man mit "tail dateiname" z.B. auslesen.

  8. #8
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Im Buch wird erwähnt, dass Unit of Work auch die Nebenläufigkeit steuern soll. D.h. doch, dass wenn User A ändernd auf Ressource A zugreift ein User B bspw. nicht mehr auf Ressource A zugreifen darf, oder?
    Da macht aber ein DB-Lock mehr Sinn ^^
    @DB: Es ist doch ein Unterschied, die Objekte mit einem Request wieder herzustellen anstatt diese neu zu erstellen mit X Requests? Also ich finde das macht schon Sinn!
    Dann kannstes auch ganz banal cachen und brauchst dafür keinen neuen Mechanismus.

    Ma was anderes: Wenn ich das mache, damit die Objekte nich alle Nase lang in die DB schreiben. Wann solln das dann in die DB geschrieben werden?

  9. #9
    Erfahrener Benutzer Avatar von Blackflash
    Registriert seit
    18.02.2007
    Beiträge
    399
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Ich sehe es so, dass es wie eine Art Transaktion ist, die sich über mehrere Requests erstreckt. Zumindest wäre das einer der wenigen Fälle, in denen es einigermaßen effektiv ist. Man sollte mit einer Unit of Work nur einen Benutzer bedienen, da sich der Aufwand ansonsten definitiv nicht lohnt. Locking sollte man definitiv implementieren, es ist nur die Entscheidung, welchen Lock man verwendet (in dem Buch stehen ja mehrere zur Auswahl).
    Ich würde die Unit of Work übrigens in der Session ablegen, wie bereits vorgeschlagen, da es ansonsten sinnlos ist. Alternativ könnte man es auch im RAM ablegen bzw. Zend_Cache nutzen. Gibt in dem Fall viele Möglichkeiten, aber ich behaupte, dass sich die Unit of Work erst lohnt, wenn man größere Geschäftsprozesse (Transaktionen) über mehrere Requests benötigt, da es doch recht komplex wird, wenn man es wirklich robust programmieren möchte, was definitiv empfehlenswert ist. In Java wäre so was kein Problem, aber PHP ist dafür nicht prädestiniert.

    Das Schreiben in die Datenbank würde ich erledigen, wenn die Transaktion zuende ist.

  10. #10
    Neuer Benutzer
    Registriert seit
    25.10.2007
    Beiträge
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Also erstmal Danke für die vielen konstruktiven Beiträge. Ich nehme jetzt mal folgende Erkenntnisse für mich mit:
    • Unit of Work sammelt lediglich die Änderungen eines Benutzers über die während einer Geschäftstransaktion (die aus mehreren Requests bestehen kann) bearbeiteten Objekte.
    • Am Ende der Geschäftstransaktion versucht Unit of Work alle Änderungen in die Datenbank zu schreiben.
    • Die Nebenläufigkeitssteuerung ist nicht Bestandteil von Unit of Work sondern muss eigenständig über ein geeignetes Locking Verfahren realisiert werden. Unit of Work reagiert lediglich auf das Locking.
    Ich hoffe ich hab das jetzt richtig dargestellt . Für mich heißt das, dass ich mich am Wochenende mal mit Locking beschäftigen muss und ich glaube das wird nicht so einfach

  11. #11
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Das einfachste Locking ist Manuell
    Code:
    locked_tables
    ----
    name: String
    locked: Boolea
    Alles, was nun versucht irgendwelche Daten aus oder von der DB zu ändern, muss nun schauen, ob sie freigegeben ist

    Viele RDBMS können das aber auch schon.

  12. #12
    Erfahrener Benutzer
    Registriert seit
    12.04.2007
    Beiträge
    1.045
    Thanks
    0
    Thanked 3 Times in 2 Posts

    Standard

    Hallo Benjamin,

    was für ein Anwendungsszenario schwebt Dir denn konkret vor, um dieses Pattern in der Praxis einzusetzen?

    Gruß
    Remi

  13. #13
    Neuer Benutzer
    Registriert seit
    25.10.2007
    Beiträge
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Hallo Remi,

    ein konkretes Anwendungsszenario schwebt mir momentan nicht vor. Ich habe halt die Theorie über das Unit of Work gelesen und mich gefragt wie man das mit PHP umsetzen könnte. Ich sehe den Vorteil des Unit of Work bei komplexen / langwierigen Geschäftstransaktionen, damit
    • nicht viele kleine Updates auf die DB gemacht werden (Performance)
    • bei einem Abbruch durch Infrastruktur/Benutzer bereits auf die Datenbank geschriebene Änderungen nicht rückgängig gemacht werden müssen (Datenqualität)
    • man sehr einfach nachvollziehen kann welche Geschäftstransaktion welche Objekte angepasst hat bzw. auf welche Tabellen der Datenbank Einträge geschrieben wurden (hierzu müssen die Einträge der Unit of Work gespeichert werden)
    Einsetzen würde ich das Unit of Work Pattern vermutlich bei
    • Online Bestellungen
    • Projektverwaltung mit vielen abhängigen Meilensteinen / Aufträgen deren Änderung Auswirkungen auf andere Projekte,... haben
    • Verwaltung/Beabeitung eines Versicherungsvertrags
    Das sind die besten Beispiele die mir momentan einfallen Wie siehst du das?

    Gruß Benjamin

  14. #14
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Online Bestellungen
    Warenkorb in Session OK, könnte man als solche Pattern implementieren ^^
    Projektverwaltung mit vielen abhängigen Meilensteinen / Aufträgen deren Änderung Auswirkungen auf andere Projekte,... haben
    Da würde ich eher jede Komponente für sich betrachten, also zB Auftrag für ein Milestone ist erst möglich, wenn der Milestone existiert, anstatt alles in einen Prozess zu erledigen.
    Verwaltung/Beabeitung eines Versicherungsvertrags
    Ähm ... Ja

  15. #15
    Erfahrener Benutzer
    Registriert seit
    10.09.2007
    Ort
    Wuppertal
    Beiträge
    5.725
    Thanks
    1
    Thanked 41 Times in 40 Posts

    Standard

    Mir würde noch spontan einfallen, Benutzer zu zwingen, eine Transaktion zuende zu führen, wenn z.B. mehrere Schritte getan werden müssen, um einen Vertrag abzuschließen, da der Prozess sich auf mehrere Seiten verteilt...

  16. #16
    Erfahrener Benutzer
    Registriert seit
    12.04.2007
    Beiträge
    1.045
    Thanks
    0
    Thanked 3 Times in 2 Posts

    Standard

    Es wird als Session realisiert, deren Daten von jeder Seite zu Seite (bei einem Assistenten) weiter anwachsen oder bei der immer weitere Produkte hinzugefügt werden (bei einem Warenkorb) und zum Schluß dann in einem Rutsch abgeschickt werden (wenn Kreditkartenzahlung erfolgreich war). Hierfür ist PHP geradezu prädestiniert. Das Zend Framework bietet eine nette Session-Unterstützung (Zend_Session), mit der Du solche Anwendungen bauen kannst.

    Beispiel Warenkorb:
    • Merken der ausgewählten Artikel in der Session
    • Benutzer kann weiter einkaufen (neue Artikel suchen und hinzufügen) oder im Warenkorb befindliche Artikel abändern/löschen
    • Merken der Zahlungsweise, Lieferanschrift, ...
    • Kreditkartenzahlung online durchführen
    • komplette Bestellung speichern
    • Bestätigung anzeigen

    Beispiel Versicherungsvertrag:
    • Merken der Versicherungsmerkmale
    • Benutzer kann weitere Merkmale hinzufügen oder zu vorherigen Schritten zurückspringen, um seine Daten zu ändern
    • Tarife anfragen und anzeigen
    • weitere Versicherungen können der Session hinzugefügt werden, hierbei können sich ggf. auch Preisermäßigungen für bereits ausgewählte Versicherungen ergeben
    • kompletten Vorgang speichern
    • Bestätigung anzeigen

    Wieviel Vorgänge in eine Session gepackt werden, bevor sie schlußendlich abgeschickt und damit gespeichert wird, ist von der jeweiligen Anwendung abhängig. Wenn ein Kunde stundenlang Artikel zum Warenkorb hinzufügt und die Bestellung erst nach 5 Stunden abschickt, kann es sein, dass die Artikel mittlerweile nicht mehr verfügbar (da mittlerweile an andere Kunden verkauft) sind. Deshalb wird in der Praxis die Dauer einer Session meist beschränkt, mindestens jedoch bei Übergabe der Bestellung überprüft, ob die Bestellung vom System angenommen wurde.

    Beispiel: Buchen von Urlaubsreisen
    1. Erst wird eine Buchungsanfrage gemacht.
    2. Nun kann der Benutzer überlegen.
    3. Erst zum Schluß wird der Vorgang in einem Rutsch eingebucht. Sollte die Reise dann zwischenzeitlich ausgebucht sein, gibt es eine entsprechende Meldung.

    Auch für das Beispiel mit der Projektverwaltung könnte es kritisch sein, arg zu viel Schritte in der Session zwischenzuspeichern, bevor die Daten dann in die Datenbank eingetragen werden. Hängt alles vom konkreten Anwendungsszenario und der erwarteten Anzahl konkurrierender Transaktionen ab.

    Remi

  17. #17
    Erfahrener Benutzer
    Registriert seit
    10.09.2007
    Ort
    Wuppertal
    Beiträge
    5.725
    Thanks
    1
    Thanked 41 Times in 40 Posts

    Standard

    Zitat Zitat von Remi Beitrag anzeigen
    Es wird als Session realisiert, deren Daten von jeder Seite zu Seite (bei einem Assistenten) weiter anwachsen oder bei der immer weitere Produkte hinzugefügt werden (bei einem Warenkorb) und zum Schluß dann in einem Rutsch abgeschickt werden (wenn Kreditkartenzahlung erfolgreich war). Hierfür ist PHP geradezu prädestiniert. Das Zend Framework bietet eine nette Session-Unterstützung (Zend_Session), mit der Du solche Anwendungen bauen kannst.

    Beispiel Warenkorb:
    • Merken der ausgewählten Artikel in der Session
    • Benutzer kann weiter einkaufen (neue Artikel suchen und hinzufügen) oder im Warenkorb befindliche Artikel abändern/löschen
    • Merken der Zahlungsweise, Lieferanschrift, ...
    • Kreditkartenzahlung online durchführen
    • komplette Bestellung speichern
    • Bestätigung anzeigen

    Beispiel Versicherungsvertrag:
    • Merken der Versicherungsmerkmale
    • Benutzer kann weitere Merkmale hinzufügen oder zu vorherigen Schritten zurückspringen, um seine Daten zu ändern
    • Tarife anfragen und anzeigen
    • weitere Versicherungen können der Session hinzugefügt werden, hierbei können sich ggf. auch Preisermäßigungen für bereits ausgewählte Versicherungen ergeben
    • kompletten Vorgang speichern
    • Bestätigung anzeigen

    Wieviel Vorgänge in eine Session gepackt werden, bevor sie schlußendlich abgeschickt und damit gespeichert wird, ist von der jeweiligen Anwendung abhängig. Wenn ein Kunde stundenlang Artikel zum Warenkorb hinzufügt und die Bestellung erst nach 5 Stunden abschickt, kann es sein, dass die Artikel mittlerweile nicht mehr verfügbar (da mittlerweile an andere Kunden verkauft) sind. Deshalb wird in der Praxis die Dauer einer Session meist beschränkt, mindestens jedoch bei Übergabe der Bestellung überprüft, ob die Bestellung vom System angenommen wurde.

    Beispiel: Buchen von Urlaubsreisen
    1. Erst wird eine Buchungsanfrage gemacht.
    2. Nun kann der Benutzer überlegen.
    3. Erst zum Schluß wird der Vorgang in einem Rutsch eingebucht. Sollte die Reise dann zwischenzeitlich ausgebucht sein, gibt es eine entsprechende Meldung.

    Auch für das Beispiel mit der Projektverwaltung könnte es kritisch sein, arg zu viel Schritte in der Session zwischenzuspeichern, bevor die Daten dann in die Datenbank eingetragen werden. Hängt alles vom konkreten Anwendungsszenario und der erwarteten Anzahl konkurrierender Transaktionen ab.

    Remi
    Dann habe ich das immer intuitiv genutzt *g* Nur wie gesagt, Wenn die Session-Dateien serverseitig zu groß werden hemmt das die Performance.

  18. #18
    Erfahrener Benutzer Avatar von Blackflash
    Registriert seit
    18.02.2007
    Beiträge
    399
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Ich glaube, es gibt einen signifikanten Unterschied zwischen dem Speichern von Daten in der Session und der Unit of Work. Zum Einen ist die Unit of Work ein abstrahiertes Gebilde, wie z.B. ein Warenkorb, aber was noch viel wichtiger ist: Es muss selbst mit der Datenbank korrespondieren und in vielen Fällen zwischen Datenbank und Business-Code gesetzt werden.

    Da ich die Unit of Work bisher noch nicht implementiert habe, kenne ich allerdings nicht die gesamten Nuancen. ;-)

  19. #19
    Erfahrener Benutzer
    Registriert seit
    12.04.2007
    Beiträge
    1.045
    Thanks
    0
    Thanked 3 Times in 2 Posts

    Standard

    Hallo Blackflash;

    welche praktischen Anwendungsszenarien gibt es denn dann für das Pattern? (Für die bisher vorgestellten Anwendungen sind Sessions empfehlenswert.)

    Remi

  20. #20
    Erfahrener Benutzer
    Registriert seit
    12.04.2007
    Beiträge
    1.045
    Thanks
    0
    Thanked 3 Times in 2 Posts

    Standard

    Ich habs nun bei Fowler nochmal nachgelesen: http://martinfowler.com/eaaCatalog/unitOfWork.html

    Dabei fiel mir auf, dass der Datastore vom DojoToolkit ein schönes Beispiel für das Unit of Work-Pattern ist:
    1. Der Browser lädt per AJAX/JSON Daten in ein GridWidget.
    2. Der Benutzer editiert dort Zeilen und/oder fügt neue Zeilen hinzu bzw. löscht sie.
    3. All diese Operationen finden im Client (hier der Browser) statt. Erst wenn der Benutzer auf "Speichern" klickt, werden sämtliche als "dirty" markierte Datensätze per AJAX/JSON an den Server geschickt.
    4. Auf Seiten des Servers werden die Änderungen in einem Durchlauf (idealerweise in einer Transaktion) abgearbeitet.
    5. Der Client erhält eine Bestätigungs- oder Fehlermeldung zurück.
    siehe auch:
    Remi

Seite 1 von 2 1 2 LetzteLetzte

Ähnliche Themen

  1. MVC-Pattern auf einfaches Kontaktform anwendbar?
    Von SoulReaver im Forum Einsteigerfragen
    Antworten: 1
    Letzter Beitrag: 19.08.2007, 00:46
  2. Wo am besten eine Menü implementieren?
    Von tsedeke im Forum Einsteigerfragen
    Antworten: 25
    Letzter Beitrag: 30.06.2007, 02:21

Lesezeichen

Berechtigungen

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