[SF][Symfony2]Płatności payU, Konwersja do API, używać interface'u? Opcje

[mimol]

Witam,
Stworzyłem sobie wypożyczalnie filmów i podpiąłem do tego płatności.
Płatności stworzyłem jako osobny bundle.
Jednak nie wiem jak zorganizować konwersję z mojej encji na taką która pasowała by do payU API.
Obecnie w bundlu płatności mam plik convert, który zamienia wartości z encji i przypisuje je tak aby pasowały do API. Wiem, że to jest zły sposób (w płatnościach nie powinno być to raczej robione)
Następna wada, jeśli sprzedawał bym bilety, również musiał bym stworzyć taki plik.
Jak się za to zabrać?
Myślałem nad stworzeniem interfacu(bilety, i filmy musiały by mieć takie funkcje jak: getItems, getShippingCost, etc).
Jak powonieniem zorganizować położenie plików?
Interface powinien być gdzieś w bundlu płatnośći, klasa która implementuje pewnie w danym bundlu(filmy, bilety). Tylko gdzie dokładnie powinny znajdować się pliki?
Może platności powinienem zrobić jako usługę?
Jeśli macie jakieś podpowiedzi/pomysły proszę o opinię

[m44]

A obecnie ten plik odpowiedzialny za konwersję danych z encji to jakiś plik z klasą czy zrobiłeś to inaczej?

[mimol]

Jest to klasa Conventer, i zawiera te kilka funkcji

[m44]

A same przedmioty na sprzedaż w Twoim systemie - pisałeś że są to filmy. Masz to jakoś ujednolicone jako ogólny przedmiot, który może być filmem i biletem, czy jakimkolwiek innym produktem, czy encja biletów jest zrobiona "na sztywno"?

[mimol]

Co to za różnica?(Nie, nie jest ogólnym przedmiotem, nie mam jeszcze biletów (podane jako przykład)) Widzę, że nie rozumiesz moich pytań.
Czy powinienem stworzyć interface? Jeśli tak to gdzie powinny znajdować się pliki?
Jeśli nie to podaj jakieś inne pomysły

Ten post edytował mimol 1.05.2013, 11:41:55

[m44]

To pytanie ma znaczenie, bo gdybyś miał ogólną encję produktu, który jest dodatkowo charakteryzowany przez cechy lub kategorie to interfejs, który masz zamiar stworzyć mógłby agregować właśnie taką encję lub także jej interfejs, co byłoby bardziej elastyczne.

No ale jak masz osobne encje, to możesz zrobić tak jak pisałeś. Stworzyć sobie interfejs, implementować go w klasach i skonfigurować całość jako serwisy. Tyle tylko, że w przypadku kolejnych produktów np. biletów i tak zmienia Ci się tożsamość obiektu, więc nie wiem jak będziesz chciał przekazywać encję do tego samego serwisu konwertującego obiekt encji. Chyba, że nie zrobisz tam wymuszenia typu tylko będziesz to sprawdzał przez instanceof lub zrobisz coś na wzór wzorca strategii, który w locie wybiera serwis konwertujący. Gdybyś przekazywał do serwisu zawsze np. jakiś ProductInterface miałbyś zagwarantowane na poziomie samych obiektów, że produkty są produktami, niezależnie od danych szczegółowych.

Ewentualnie możesz stworzyć sobie taki ProductInterface i implementować go w każdej encji osobno (wcześniej oczywiście wyszczególniając wszystkie cechy wspólne), np. dla biletów i filmów do wypożyczenia, a w samych serwisach konwertujących oczekiwać na podanie właśnie tego obiektu implementującego interfejs produktu.

[mimol]

To pytanie ma znaczenie, bo gdybyś miał ogólną encję produktu, który jest dodatkowo charakteryzowany przez cechy lub kategorie to interfejs, który masz zamiar stworzyć mógłby agregować właśnie taką encję lub także jej interfejs, co byłoby bardziej elastyczne.
No ale jak masz osobne encje, to możesz zrobić tak jak pisałeś.

Pisałem, że biletów nawet nie mam (podane jako przykład)

Stworzyć sobie interfejs, implementować go w klasach i skonfigurować całość jako serwisy.

Co to są serwisy? Masz na myśli usługi?

Czy powinienem stworzyć interface? Jeśli tak to gdzie powinny znajdować się pliki?

Chyba na żadne pytanie mi nie odpowidzałeś...