Ankündigung

Einklappen
Keine Ankündigung bisher.

Design Konzept, Listener, Observer, Proxy, Decorator, ..?

Einklappen

Neue Werbung 2019

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

  • Design Konzept, Listener, Observer, Proxy, Decorator, ..?

    Hi,

    ich bau gerade ein Frontend, welches per REST API mit einem Backend kommuniziert. Ich benutze das Zend Framework 2. Konkret lädt man Übersetzungen, Sprachen, Projekte.

    Jetzt werden Sprachen sehr oft bezogen, aber sehr selten geändert. Daher soll der API-Aufruf für Sprachen gecachet werden.

    cache /language/list solange bis /language/create | update | delete aufgerufen wird
    Außerdem möchte ich die zuletzt geladenen Sprachen priorisiert anzeigen

    Recently used: German, English, French
    So lade ich derzeit Sprachen:

    PHP-Code:
    <?php
    $manager 
    $this->getServiceLocator()->get('languageManager');
    $language $manager->get(123);
    ?>
    Daran möchte ich eigentlich auch nichts ändern, sprich "languageManager" soll diese Features bereits integrieren.

    Ich bin mir nicht sicher, welches Design Pattern jetzt für mich in Frage kommt.

    Observer, Listener, Proxy, Decorator?

    Ganz blöd stell ich mir das so vor:

    PHP-Code:
    <?php
    $manager 
    = new ApiLanguageManager($config);
    $manager = new CachedLanguageManager($cache$manager);
    $manager = new LogLanguageManager($db$sessionUser$manager);
    $language $manager->get(123);

    interface 
    LanguageManagerInterface
    {
      public function 
    get($id);
    }

    class 
    ApiLanguageManager implements LanguageManagerInterface
    {
      public function 
    get($id) {
        return 
    $this->curl->request('/api/url/language/123');
      }
    }

    class 
    CachedLanguageManager implements LanguageManagerInterface
    {
      public function 
    get($id)
      {
        if (!
    $this->cache->has('languages')) {
          
    $this->cache->set('languages'$this->manager->getList());
        }
        return 
    $this->cache->get('languages')->get($id);
      }
    }

    class 
    LogLanguageManager implements LanguageManagerInterface
    {
        public function 
    get($id)
        {
          
    $language $this->manager->get($id);
          
    $this->db->insert('user_language', array('uid' => $this->uid'type' => 'loaded''lid' => $language->getId()));
          return 
    $language;
        }
    }
    ?>
    Welche Vor- und Nachteile hat dieses Konzept (ist das überhaupt eins, welches, Decorator?) bezüglich Wartbarkeit/Debugging/Flexibilität eurer Meinung nach?
    Wie wäre eure Vorgehensweise?
    Sind beide TODOs unter einen Hut zu bringen?

    Ich habe halt die Befürchtung, dass Observer, Event Manager, Listener oder ähnliches nicht einfach umzusetzen sind; und es soll ja einfach sein (simplicity). Damit will ich nicht sagen, ich schließe bewährte Konzepte aus, nur weil ich sie nicht für einfach halte (oder kapiere) - aber ich kann mir gerade nicht vorstellen, wie ich das ganze einfach halte, wenn das ganze dann noch für Projekte oder andere Entitäten so funktionieren soll.

    Danke & Gruß,
    Chriz
    "Mein Name ist Lohse, ich kaufe hier ein."


  • #2
    Jemand einen Ansatz? Oder ist das Posting unverständlich?
    "Mein Name ist Lohse, ich kaufe hier ein."

    Kommentar


    • #3
      also als Event Manager kannste ja das Symfony Teil in dein Projekt einbinden: https://github.com/symfony/EventDispatcher

      ich kann jetzt nicht allzu viel über Zend sagen - in Symfony könnte man Routen über die @Cache Annotation die Response cachen: http://symfony.com/doc/current/bundl...ons/cache.html

      du könntest also den Event Dispatcher als Service in den Zend DI bauen und dann könntest du Event Listener dran hängen, der sich dann um das Caching kümmert.

      Ich hoffe, ich konnte dir etwas weiterhelfen,

      Ma27
      https://github.com/Ma27
      Javascript Logic is funny:
      [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

      Kommentar


      • #4
        Was sich aus meiner Sicht für dich anbieten würde, wäre ein Strategy-Pattern. Du könntest dazu zusätzlich, um die Kommunikation vom Kontext zum Client zu reduzieren, eine Static Factory einsetzen, die dir die jeweilige Instanziierungen vom Client abnimmt.

        Ein Dispatcher (im Sinne von Zend-Style) ist auch keine abwegige Idee. Das erlaubt dir via pre- und postDispatches beliebig "forward-Verarbeitungen" durchzuführen, was sich für das Caching/Logging ideal anbieten würde. Alternativ kannst du vom Dispatcher ableiten und somit ein eigenes Verarbeitungsparadigma definieren.

        Kommentar

        Lädt...
        X