Ankündigung

Einklappen
Keine Ankündigung bisher.

Datenbankkommunikation über Events

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Datenbankkommunikation über Events

    Hallo,

    das Durchreichen von Datenbank-Adaptern für ActiveRecord oder die Benutzung von Singleton um die Datenbank-Instanz zu holen stört mich gerade.

    Ich habe mir überlegt ob eine User-Klasse nun nicht einen Event werfen könnte um wer auch immer sich für diesen Event eingetragen hat, die Speicherung übernehmen zu lassen.

    User.class.php
    PHP-Code:
    <?php
    class User {
      
    // ..
      
    public function save() {
        
    $event = new Event(__METHOD__$this);
        
    $event Registry::get("EventDispatcher")->trigger($event);
        return 
    $event->getSuccess()
      }
      
    // ..
    ?>
    events.inc.php
    PHP-Code:
    <?php
    $eventDispatcher 
    = new EventDispatcher();
    $eventDispatcher->handle("User::save", new Database_Csv());
    $eventDispatcher->handle("Mailbox::save", new Database_Mysql());
    // ..
    Registry::set("EventDispatcher"$eventDispatcher);
    ?>
    Im Prinzip geht das ja in Richtung Inversion of Control, welches ja auch im Zusammenhang mit Dependency Injection genannt wird. Letzteres scheint mir allerdings etwas kompliziert (ja die Scheu) bzw. etwas zu überladen.

    Was haltet ihr von der Event-basierten Speicherung? Im Event-Kontext könnte ich ja alle Informationen ablegen, um mehr als nur "getSuccess" als Feedback anzubieten, eben auch das Transportieren von Werten (User-Eigenschaften zu read()).

    Was wäre eure Meinung dazu?

    Wie ich dadrauf gekommen bin der Vollständigkeit halber:
    Designfrage 2: das leidige mitschleifen von Parametern - Forum: phpforum.de
    "Mein Name ist Lohse, ich kaufe hier ein."


  • #2
    Habe ich noch nicht ganz durchdrungen. Wer speichert (die User Klasse), unn wo treten die Daten auf bzw. wie werden sie übergeben (liest die angetriggerte Funktion die dann über eine Methode aus dem Event-erzeugenden Objekt oder wie)?

    [edit]
    Habe jetzt auch die anderen Forenbeiträge gelesen. Was gegen Singleton und ähnliche Konstrukte spricht, kann ich noch nicht ganz nachvollziehen.
    Wie wärs mit einem spezialisierten Objekt, das bspw. von Datenbankobjekt erbt (und seine Connection und Methoden nutzt) aber mit bspw. User-Objekten umgehen kann? Diesem bräuchtest Du dann nur das User-Objekt zu übergeben und 'save () zu drücken'.
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      Zitat von nikosch Beitrag anzeigen
      Habe ich noch nicht ganz durchdrungen. Wer speichert (die User Klasse), unn wo treten die Daten auf bzw. wie werden sie übergeben (liest die angetriggerte Funktion die dann über eine Methode aus dem Event-erzeugenden Objekt oder wie)?
      Der EventHandler, der sich konkret für "User::save" registriert hat bekommt den Event an seine Interface-Methode handle(Event $event) übergeben. Ein Event besitzt eine $context Property, in der alles abgelegt werden kann, was den Event ausmacht, z.B. das konkrete User-Objekt.

      Letztlich landet also das User-Objekt bei new Database_Csv() oder wem auch immer, der natürlich dafür ausgelegt sein muss. Im Prinzip also ein Mapper, wie du es hier auch geschrieben hast:
      Wie wärs mit einem spezialisierten Objekt, das bspw. von Datenbankobjekt erbt (und seine Connection und Methoden nutzt) aber mit bspw. User-Objekten umgehen kann? Diesem bräuchtest Du dann nur das User-Objekt zu übergeben und 'save () zu drücken'.
      Mit dem Vorteil, dass außer dem EventDispatcher niemand weiß, wer das Objekt nun gespeichert hat.
      "Mein Name ist Lohse, ich kaufe hier ein."

      Kommentar


      • #4
        Mit dem Vorteil, dass außer dem EventDispatcher niemand weiß, wer das Objekt nun gespeichert hat.
        Und das irgendwann dermaßen intransparent wird...
        Viele Grüße,
        Dr.E.

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        1. Think about software design before you start to write code!
        2. Discuss and review it together with experts!
        3. Choose good tools (-> Adventure PHP Framework (APF))!
        4. Write clean and reusable software only!
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Kommentar


        • #5
          Hallo!
          Ich denke dieser Thread aus dem Adventure-PHP-Forum sollte auch für dich interessant sein. Dort geht es um eine Implementierung des DataMapper Patterns von Martin Fowler. Würde mich freuen, wenn du dich ebenfalls an der Diskussion beteiligst.
          MfG, Andy

          Kommentar


          • #6
            Wo hat die Diskussion denn begonnen?
            "Mein Name ist Lohse, ich kaufe hier ein."

            Kommentar


            • #7
              Hallo Chriz,

              per PN. Vielleicht kann Andy diese ja hier oder im APF-Forum zur Verfügung stellen.
              Viele Grüße,
              Dr.E.

              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              1. Think about software design before you start to write code!
              2. Discuss and review it together with experts!
              3. Choose good tools (-> Adventure PHP Framework (APF))!
              4. Write clean and reusable software only!
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

              Kommentar


              • #8
                Stelle mal schnell beide PNs im APF-Forum rein.
                MfG, Andy

                Kommentar

                Lädt...
                X