Gdzie umieścić kod od api? Opcje

[sazian]

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ę

[ohm]

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ł)

[sazian]

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 ?

[ohm]

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,

[sazian]

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

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ś

[ohm]

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-intro...-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.

[sazian]

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

Ten post edytował sazian 18.10.2023, 19:33:46

[Salvation]

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.

[sazian]

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?

[Salvation]

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.

Ten post edytował Salvation 26.10.2023, 20:58:57

[sazian]

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/...

[Salvation]

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.

[sazian]

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

[Salvation]

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/