Drukowana wersja tematu

Kliknij tu, aby zobaczyć temat w orginalnym formacie

Forum PHP.pl _ PHP _ Gdzie umieścić kod od api?

Napisany przez: sazian 18.10.2023, 17:55:35

Ostatnio ze znajomymi mieliśmy rozkminię na temat gdzie umieścić kod klienta api i jak wiadomo gdzie 3 osoby tam 4 opinie.
Ja jestem za opcją że api powinno być w modelu, ponieważ to model odpowiada za komunikację z zewnętrznymi zasobami.
Ale były osoby które uważał że to powinno być "gdzieś indziej" nie wiadomo gdzie ale nie wiadomo gdzie tylko nie model bo się robi bałagan, model tylko do bazy danych. Może jakaś biblioteka, może coś innego ale nie model.

Gdzie wy byście to wstawili?

Nie pytam gdzie wstawić adres api czy klucze tylko kod odpowiedzialny za komunikację

Napisany przez: ohm 18.10.2023, 17:56:12

wg mnie model tylko "modeluje" dane, a nie wykonuje logiki jako takiej, logika powinna byc osobno, chociażby w jakimś namespace ApiClient (zwał jak zwał)

Napisany przez: sazian 18.10.2023, 18:01:08

Co rozumiesz przez "modeluje"?

Jeśli potakujemy model jako encje do tabeli w bazie to robi to samo co api, pobiera dane, aktualizuje dane, dodaje itd...

A jeśli chodzi o to ApiClient to rozumiem że jak w mvc masz przykładowo takie katalogi
app/model
app/view
app/controller

to dodałbyś app/ApiClient ?

Napisany przez: ohm 18.10.2023, 18:59:52

Tzn ja wyznaję zasadę że model jest tylko przedstawieniem danych, a sam model nie powinien mieć logiki, czyli to nie model powinien zapisywać tylko być zapisywany/odczytywany do/z bazy przez ORM. A klient API powinien działać na zasadzie podobnej co ORM, czyli odczytywac/wysyłać dane na podstawie danych z modeli.

Co do samej struktury to już zależy od projektu, przyjętego nazwenictwa, PSRów itp, moze byc np app/api/client,

Napisany przez: sazian 18.10.2023, 19:07:50

Ale przecież to właśnie model odpowiada za logikę biznesową
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller#Model

Cytat

It directly manages the data, logic and rules of the application

Więc w takim razie gdzie umieszczasz logikę?
Serio pytam bo mnie teraz zainteresowałeś

Napisany przez: ohm 18.10.2023, 19:13:50

Częsciowo w kontrolerach i glownie w "serwisach", tzn możliwe że ja patrze przez pryzmat MVC w symfony i dlatego może być to odrobinę "dziwne"
https://symfony.com/legacy/doc/gentle-introduction/1_4/en/02-Exploring-Symfony-s-Code -
https://symfony.com/legacy/images/book/1_4/F0201.png / https://symfony.com/legacy/images/book/1_4/F0202.png i przyjąłem sposób że entity jest właśnie przedstawieniem modelu i ogólnie model służy jako "przechowywalnia" danych.

Napisany przez: sazian 18.10.2023, 19:33:28

Czy ty pracujesz na frameworku wydanym 11lat temu?

Szczerze to teraz jak patrzę na z linku który wstałeś to przestaję się dziwić bo tam to co jest nazywane modelem to funkcja pobierając dane z bazy i zapisująca je do tablicy.

Chociaż w takim przypadku mównice dobrze mogłaby być funkcja/model pobierająca dane z api

Napisany przez: Salvation 23.10.2023, 16:03:53

Zewnętrzne API powinno być zamknięte serwisem (warstwą abstrakcji) i wstrzykiwane do serwisów aplikacji. Najlepiej będzie jak zamkniesz je sobie albo w osobnej paczce i dorzucisz przez composera, albo wydzielisz sobie katalog zaraz pod /src/ i tam sobie zamkniesz domenę tego API.

Napisany przez: sazian 24.10.2023, 15:20:35

Przez composera jakoś mi się nie podoba bo jak zaczynasz pracować z api to na sam start nie wiesz co będziesz dokładnie potrzebował, a każda drobna zmiana wiąże się z podnoszeniem wersji i aktualizacją composera.

No dobra ale powiedzmy że robisz tą bibliotekę lub /src/jakieśApi i co dalej? Jaką to ma dalej strukturę plików?

Napisany przez: Salvation 26.10.2023, 20:58:00

Podzielone przez moduły. Products, Categories, itp... Zależy co to API ma robić. No i może się przydać podejście 1 Route = 1 Controller.

I tak. Przez composera, to dobra droga, jeżeli wypuszczasz paczkę dla większej ilości klientów niż twoja aplikacja.
Załóżmy, że komunikujesz się z bramką płatniczą. Robisz więc API jako paczkę i wypuszczasz na packagista. Dorabiasz endpointy / merge'ujesz PR-ki, to zwiększasz wersję.

No bo API, to nie tylko URL a cały zestaw interfejsu. Wypuszczone metody przez Interface, to też API.

Napisany przez: sazian 29.10.2023, 21:45:21

Założenie jest takie że to będzie tylko do użytku wewnętrznego, nie będzie nigdzie publikowane.
Dla uproszczenia można założyć że to API czegoś popularnego jak allegro czy inpost. Ale równie dobrze może t być coś znacznie bardziej niszowego jak przykładowo jakaś hurtownia gdzie coś takiego jak dokumentacja często nie do końca istnieje lub mija się z prawdą.

Czyli w taki przypadku przy rozwiązaniu z modelami robimy po prostu przestrzenie nazw model/allegro/... czy model/inpost/...

Napisany przez: Salvation 30.10.2023, 09:14:25

Byłym daleki od używania słowa Model, ale zgadzam się z konwencją. Wewnątrz /inpost/ podział już wg danej domeny, który może pokrywać się z tym z /allegro/ czy innym.

Napisany przez: sazian 30.10.2023, 17:57:26

A czemu nie model?
W MVC model odpowiada za logikę biznesową oraz jest encją danych. Więc pasuje idealnie.

Napisany przez: Salvation 30.10.2023, 18:41:36

Właśnie tego się obawiałem, że będziesz to utożsamiał z logiką biznesową i - co gorsza - z Encją.
Otóż model, to prezentacja danych, czyli raczej Prezenter, bo na 100% nie chcesz wyświetlać wszystkiego z Entity i na 100% nie trzymasz w nim logiki biznesowej. Tutaj idealnie sprawdzi się wzorzec DTO (Data Transfer Object) i VO (Value Object).

W Sf rolę klasycznego Modelu, przejęły Services i Repositories. Jest to o wiele lepsze rozwiązanie, bo bardziej skalowalne i SOLID-ne.

Plus jeszcze jedna rzecz. Nie ma już praktycznie projektów w klasycznym MVC.
Tutaj art. do poczytania i poszerzenia wiedzy: https://www.makeuseof.com/mvc-mvp-mvvm-which-choose/