Gdzie umieścić kod od api? |
Gdzie umieścić kod od api? |
18.10.2023, 17:55:35
Post
#1
|
|
Grupa: Zarejestrowani Postów: 1 045 Pomógł: 141 Dołączył: 19.09.2006 Skąd: B-tów Ostrzeżenie: (0%) |
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ę |
|
|
18.10.2023, 17:56:12
Post
#2
|
|
Grupa: Zarejestrowani Postów: 621 Pomógł: 144 Dołączył: 22.12.2010 Ostrzeżenie: (0%) |
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ł)
|
|
|
18.10.2023, 18:01:08
Post
#3
|
|
Grupa: Zarejestrowani Postów: 1 045 Pomógł: 141 Dołączył: 19.09.2006 Skąd: B-tów Ostrzeżenie: (0%) |
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 ? |
|
|
18.10.2023, 18:59:52
Post
#4
|
|
Grupa: Zarejestrowani Postów: 621 Pomógł: 144 Dołączył: 22.12.2010 Ostrzeżenie: (0%) |
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, |
|
|
18.10.2023, 19:07:50
Post
#5
|
|
Grupa: Zarejestrowani Postów: 1 045 Pomógł: 141 Dołączył: 19.09.2006 Skąd: B-tów Ostrzeżenie: (0%) |
Ale przecież to właśnie model odpowiada za logikę biznesową
https://en.wikipedia.org/wiki/Model%E2%80%9...ontroller#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ś |
|
|
18.10.2023, 19:13:50
Post
#6
|
|
Grupa: Zarejestrowani Postów: 621 Pomógł: 144 Dołączył: 22.12.2010 Ostrzeżenie: (0%) |
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. |
|
|
18.10.2023, 19:33:28
Post
#7
|
|
Grupa: Zarejestrowani Postów: 1 045 Pomógł: 141 Dołączył: 19.09.2006 Skąd: B-tów Ostrzeżenie: (0%) |
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 |
|
|
23.10.2023, 16:03:53
Post
#8
|
|
Grupa: Zarejestrowani Postów: 377 Pomógł: 70 Dołączył: 15.07.2014 Ostrzeżenie: (0%) |
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.
|
|
|
24.10.2023, 15:20:35
Post
#9
|
|
Grupa: Zarejestrowani Postów: 1 045 Pomógł: 141 Dołączył: 19.09.2006 Skąd: B-tów Ostrzeżenie: (0%) |
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? |
|
|
26.10.2023, 20:58:00
Post
#10
|
|
Grupa: Zarejestrowani Postów: 377 Pomógł: 70 Dołączył: 15.07.2014 Ostrzeżenie: (0%) |
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 |
|
|
29.10.2023, 21:45:21
Post
#11
|
|
Grupa: Zarejestrowani Postów: 1 045 Pomógł: 141 Dołączył: 19.09.2006 Skąd: B-tów Ostrzeżenie: (0%) |
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/... |
|
|
30.10.2023, 09:14:25
Post
#12
|
|
Grupa: Zarejestrowani Postów: 377 Pomógł: 70 Dołączył: 15.07.2014 Ostrzeżenie: (0%) |
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.
|
|
|
30.10.2023, 17:57:26
Post
#13
|
|
Grupa: Zarejestrowani Postów: 1 045 Pomógł: 141 Dołączył: 19.09.2006 Skąd: B-tów Ostrzeżenie: (0%) |
A czemu nie model?
W MVC model odpowiada za logikę biznesową oraz jest encją danych. Więc pasuje idealnie. |
|
|
30.10.2023, 18:41:36
Post
#14
|
|
Grupa: Zarejestrowani Postów: 377 Pomógł: 70 Dołączył: 15.07.2014 Ostrzeżenie: (0%) |
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/ |
|
|
Wersja Lo-Fi | Aktualny czas: 26.09.2024 - 10:15 |