Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [SF2]Adapter Pattern
Forum PHP.pl > Forum > PHP > Object-oriented programming
kpt_lucek
Witajcie

Borykam się z pewnym problem, otóż... jestem w trakcie tworzenia skryptu mającego za zadanie "rozmawiać" z zewnętrzymi API.
Reguła jest prosta, mam obiekt bazowy, zawierający dane które powinny zostać wysłane, oraz konfigurację dostepową (klucze, id etc.) do każdego API z osobna. Sprawa niby ogólnie jasna, muszę w jakiś magiczny sposób dostarczyć dane z punktu A (mój skrypt) do punktu B (któreś z API), każde z nich ma inną strukturę, jedne akceptują kodowanie X, inne tylko parametry GET. Zastosowałem Adapter Pattern, do każdego z API przygotowałem adapter, implementujący Interface
  1. <?php
  2.  
  3. namespace Acme\DemoBundle\Service\Adapter;
  4.  
  5. use Symfony\Component\Form\Form;
  6. use Symfony\Component\Security\Core\User\UserInterface;
  7. use Acme\DemoBundle\Entity\DataStorage;
  8.  
  9. interface AdapterInterface
  10. {
  11. /**
  12.   * @param array $configuration
  13.   * @return $this
  14.   */
  15. public function setConfiguration(array $configuration);
  16.  
  17. /**
  18.   * @param UserInterface $user
  19.   * @return $this;
  20.   */
  21. public function saveConfiguration(UserInterface $user);
  22.  
  23. /**
  24.   * @param UserInterface $user
  25.   * @return array
  26.   */
  27. public function loadConfiguration(UserInterface $user);
  28.  
  29. /**
  30.   * @param string $name
  31.   * @return $this
  32.   */
  33. public function setName($name);
  34.  
  35. /**
  36.   * @return string
  37.   */
  38. public function getName();
  39.  
  40. /**
  41.   * @param DataStorage $dataStorage
  42.   * @return $this
  43.   */
  44. public function sendData(DataStorage $dataStorage);
  45.  
  46. /**
  47.   * @return Form
  48.   */
  49. public function getForm();
  50. }


Adaptery są ładowane do AdapterCollectora, który jest swego rodzaju container'em dla całej tej zgraii, przez niego przechodzą paramtery, ma on dostęp do każdego adaptera i jest wywoływany w controllerach, tak aby odpowiadać za przekazywanie danych(parametrów).


Dodatkowo, dane które są wysyłane, są zależne od użytkownika i to użytkownik określa "parametry" dostępowe poprzez formularz (także adapter zwraca ów formularz, dedykowany pod konkretne API).

Więc to z czym mam problem:
1. Czy moje podejście jest logiczne i poprawne w wyżej opisanej sytuacji, jeżeli nie, to w którym kierunku powinienem podążać?
2. API zwracają "okresowe" requesty zwrotne do aplikacji, często o zmianę parametrów przetrzymywanych lokalnie, poprawki, błędy, potwierdzenia etc., do każdego mam osobny controller i tyle o ile w przypadku 2-3 jest to do przyjęcia, to w przypadku 10 czy 20 już będzie bardzo problematyczne (w zarzązaniu). Czy powinienem kierować wszystkie requesty API -> Aplikacja do jednego controllera, a potem do konkretnego adaptera? A może inaczej?


Pozdrawiam

--edit--

W obecnej chwili, każde api wysyła request do osobnego controllera, ten wczytuje collector, zaś ten ładuje adapter i z niego wczytuje/zapisuje do niego jakieś dane. Nie wiem czy jest to optymalne, jakieś sugestie?
Xelah
Po pierwsze uprościłbym sam adapter. Jeśli Masz różne API, które działają w na różne sposoby i potrzebują różnych danych, to ich generalizacja przy pomocy interfejsu nie ma najmniejszego sensu.
Ja bym poszedł w kierunku factory. I na pewno pozbyłbym się formularza z adaptera. SRP - API wykonuje request i zwraca dane. I to w zupełności powinno wystarczyć. Formularz to już inna bajka i powinna mieć własną abstrakcję. Nie mieszałbym tego z API (znowu kłania się factory, gdzie na podstawie danych wejściowych dostajesz w odpowiedzi konkretny form implementujący jakiś interfejs).

Mam jeszcze jedno pytanie odnośnie API. Czy jest tak, że zawsze wykonujesz ten sam request tylko do różnych API, czy masz strukturę wiele-do-wiele?

Edit:

Najlepiej podaj jeden albo dwa use case-y. Wtedy będzie łatwiej dojść do tego, jakie rozwiązanie jest najodpowiedniejsze.
kpt_lucek
Odkopując:

Mam X konfiguracji PayPal i Y konfiguracji PayU (wielu klientów, wiele bramek)

Chcę aby podczas zakupu z danego "sklepu" użytkownik wybierał konkretną płatność i (najlepiej;) ) jakby przechodziło to przez jeden mechanizm (dlatego interface). Ilość konfiguracji (dla jednego użytkownika) jak i ilość bramek (paypal, payu, przelewy 24 etc) jest zmienna.

---EDIT

W praktyce, mógłbym fabryką tworzyć klienta na podstawie konfiguracji i bezpośrednio w nim dokonywać operacji na danych
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.