[qbek]

mirki, stosując się do Single Responsibility Principle w #django (drf) gdzie powinienem umiejscowić fragment kodu łączący się z zewnętrznymi API aby wszystko było "zgodnie ze sztuką"? View, Model czy jeszcze inaczej?
zasadniczo endpoint po otrzymaniu requesta pobiera dane z zewnętrznego API i zapisuje w bazie nowy obiekt jeżeli jeszcze go nie ma.
#python #programowanie

[menmikimen]

@qbek: Ja bym obok modeli i widoków utworzył "usługi", łączące się z api zew.

[Nicarim]

@qbek: @menmikimen: serwisy to dobry pomysł

[qbek]

@menmikimen: @Nicarim: odseparowane services.py i trzymane na tym samym poziomie co plik z models.py i views.py?
plus po wyciągnięciu samej akcji łączenia się z zewnętrznym API i tak muszę gdzieś odpalić wspomnianą metodę.
pytanie czy to już zrobić w Widoku czy Modelu?

myślałem też o zamknięciu kodu łączącego się z zewnętrznym API w osobną paczką (lub poszukanie gotowej), jednak wtedy ciągle zostaje problem gdzie wywołać ten kod.

[Nicarim]

@qbek: jak juz odseperujesz do services to problemem nie bedzie bys wywolal ten serwis w widoku - chodzi o to zeby tresc tego serwisu po prostu nie lezala w widoku (czyli zadna logika biznesowa)

[menmikimen]

pytanie czy to już zrobić w Widoku czy Modelu?

Jeżeli stosujesz wzorzec MVC, to wszelkie operacje na modelu (i tutaj usługach) powinny być w kontrolerze

[morsik]

@menmikimen: czyli w widoku, bo w Django nie ma MVC tylko MTV (Model-Template-View) i "widok" w Django robi to co "kontroler" w MVC ;) moar

[qbek]

@Nicarim: @menmikimen: @morsik: czyli w View który przyjmuje już jakiś request POST/GET odpalany będzie kolejny request (być może innego typu) i nie łamie to SRP o ile logika sięgnięcia do zewnetrznego API jest zaszyta gdzie indziej?

[menmikimen]

@morsik nie znam się za bardzo na Django, ale myślałem, że to template jest widokiem a funkcja podczepiona pod kontrolerem w tej implementacji

[morsik]

@menmikimen: template to tylko templatka końcowa z HTML-em. Widok to kod który pobiera dane (używjąc modelu) i wystawia zmienne do templatki. Dokładnie tak jak robi to kontroler dla widoku w MVC. Tu wyjaśnienie lepsze.

The view describes which data you see, not how you see it. It’s a subtle distinction.

[menmikimen]

@morsik
Coś źle wyklikalem i zjadło mi 2 słowa. Chodziło mi o

funkcja podczepiona pod ścieżkę URL.

No to chyba tylko różnica polega na nazwach template-widok i widok-kontroler

[Nicarim]

@qbek wedlug mnie tak jak mowisz - SRP mozesz badac od ogolu do szczegolu - ogolem w tym przypadku jest to by widok wykonal dana akcje ale zeby nie zajmowal sie wykonaniem zapytania (moze poprosic cos innego o wykonanie zapytania - i to jest ok wedlug mnie)

[morsik]

@qbek: ja tam logikę odpytywania zewnętrznego API robię bezpośrednio w funkcji widoku. Często i tak to musi być blokujące zapytanie, bo pewnie dalej coś będziesz robił. Jeśli wiesz, że nic dalej od tego nie zależy to powinieneś użyć zewnętrznego systemu kolejkowego (ale zgaduję, że to nie ten przypadek)

view.py:

def get_this_stuff(req, something):
....nie_wazne = requests.get('[http://inny.host/](http://inny.host/){}'.format(something))
....return nie_wazne

[filozof900]

@qbek: serwis uzywany z widoku jest ok, pamietaj tylko o obsludze bledow / timeoutow itd

[gryzon_c]

@qbek: Django samo w sobie łamie SRP, nie wiem czy jest sens się tego trzymać

[qbek]

@gryzon_c: brzmi ciekawie, powiedz proszę coś więcej o odstępstwach i czy są nieuzasadnione.