Hej, po długim okresie nic nie robienia, uznałem że czas napisać cokolwiek przydatnego, z potencjałem do rozbudowy. Napisałem proste api do stron typu wiki. Nigdy nie pisałem web api (zazwyczaj moje projekty to były zwykłe aplikacje webowe), prosił bym o rady typu co robię źle itp. Najbardziej liczę na porady związane z projektowaniem api, tak aby było wygodne w użytkowaniu i logiczne. Z góry dziękuję za pomoc.
https://github.com/FeRuOs/WikiApi
0
1
Po co Ci bin i obj w git?
0
nie wiem jak sie dzisiaj w webie robi, ale modele bez zadnej logiki wydaja sie dosc bezuzyteczne, jak to jest @somekind ? ;)
0
A co jest nie tak z tymi modelami (byc moze poza nazwa namespace'a)? Przeciez musi jakos to wyciagnac z bazy i zwrocic do klienta. W przypadku tak prostego API to spelnia swoja role. Najlepiej ladujmy wszedzie DDD i za wszelka cene unikajmy anemicznych modeli bo wiecie... to modne i tak sie powinno robic.
0
Aventus napisał(a):
A co jest nie tak z tymi modelami (byc moze poza nazwa namespace'a)?
tak jak napisalam - nie maja zadnej logiki tylko gettery i settery, w wielu przypadkach to wstep do programowania proceduralnego i zwiazanych z tym zlych praktyk.
Przeciez musi jakos to wyciagnac z bazy i zwrocic do klienta.
przeciez zeby wyslac to do klienta to jakis view-model i tak bylby potrzebny, nie?
W przypadku tak prostego API to spelnia swoja role.
moze i tak. przy czym jesli stosujemy zle praktyki przy prostym api (ktore raczej powinno byc dopieszczone) to co bedzie przy bardziej skomplikowanym projekcie ;)
Najlepiej ladujmy wszedzie DDD i za wszelka cene unikajmy anemicznych modeli bo wiecie... to modne i tak sie powinno robic.
nic takiego nie napisalam.
0
A co zlego widzicie w tych modelach bez logiki?
0
@katelx ale gdzie tu złe praktyki? Co najwyżej widzę kwestie nazewnictwa - klasy służące za encje umieszczone w namespace Models.
0
Modele, a szczególnie ViewModele bez logiki to standardowa sprawa, służą jako opakowanie danych i warstwa abstrakcji względem klas ORM.
@FeRuOs dlaczego usunąłeś repo?
0
Aventus napisał(a):
@katelx ale gdzie tu złe praktyki? Co najwyżej widzę kwestie nazewnictwa - klasy służące za encje umieszczone w namespace Models.
jak juz napisalam - nie wiem jakie sa standardy w web developerce.
z mojej perspektywy pisanie klasy bez logiki, za to z samymi gettero-setterami to proszenie sie o klopoty bo:
- lamie to enkapsulacje
- pozwala na mutowanie wszystkiego
- robi z klasy glupi kontener na dane i prowokuje do duplikowania kodu operujacego na tych danych (lub stworow w stylu
xxxUtils)' - wydaje mi sie dosc nudnym klepac takie puste klasy bez realnego zastosowania ;)
3
@katelx: to zależy od sytuacji. Jeśli to tylko CRUD bez żadnych transformacji danych, to nie ma jak utworzyć modelu z operacjami, potrzebne są po prostu kontenery na dane. I to dwa ich rodzaje: jeden między GUI a aplikacją (odzwierciedlający to, co użytkownik widzi albo wprowadza w jakimś formularzu - viewmodele), a drugi między aplikacją a bazą (opisujący to, jak dane są przechowywane w bazie - persistence modele).
Głównym problemem tutaj jest to, że wielu tzw. programistów próbuje umieścić te dwa modele w jednej klasie i wychodzi z tego jakiś mutant, który potem jest źródłem różnych problemów z lazy loading, select n+1, przesyłaniem nadmiarowych danych, wyświetlaniem zbędnych wartości w GUI, przypadkowym updatowaniem jakiś wartości w bazie (a czasem tworzeniem kolumn niechcący), itd. To podejście nazywa się "encja na twarz i pchasz".
A z drugiej strony, w sytuacjach, gdy jakaś logika już jest potrzebna, to zamiast stworzyć normalną logikę umieszczoną w modelu domeny, po prostu używają swoich uniwersalnych persistence-viewmodelowych klas i operują na nich strukturalnie. Co jest złe, ale moim zdaniem nie przez samą strukturalność tylko przez łamanie SRP przez te modele.
W przypadku prostej logiki (np. trzeba wyliczyć wartość jakiegoś pola) sam często stosuję "podejście strukturalne" operujące na persistence modelach. Uważam, że tworzenie dodatkowej warstwy domain modelu dla prostych przypadków byłoby po prostu przeinżynierowaniem, a wytworzenie i utrzymanie dodatkowego kodu to przecież koszt.