Wpis z mikrobloga

@vanguard2727:

Kilka uwag na szybko,
Gościu tłumaczy jak co jest zrobione co w sumie wystarczy na start, ale "dobrych praktyk" tam nie uświadczysz + używa narzędzi, które często zastępowane są jakimiś innymi bibliotekami (np. model validation).

Przy [PUT]Update pokazał, że w modelu sprawdza jakieś property, a Update przyjmuje (model, id), nie pokazał jak validować to id.

W repository zwraca id obiektu, który stworzył/usunął, a nic z tym nie robi (to po
@lol3pdg: podepne sie pod ten repository pattern. Jezeli mam w swoim projektcie generyczne repozytorium to implementujac dla encji tylko do odczytu pisze tylko metody GET, a u reszty metod (np. POST) zostawiam notimplementedexception?
A co do routingu, dobrze to opisał, że stosuje się adnotacje do tworzenia endpointów?


@vanguard2727:

Zależy jakie, masz jakieś konkretne na myśli czy ogólnie? Bo ogólnie to tak, ale jak masz mappera to bez sensu wpisywać "JSONProperty" czy "FromRoute" w modelu, który przyjmujesz w endpointach
Jezeli mam w swoim projektcie generyczne repozytorium to implementujac dla encji tylko do odczytu pisze tylko metody GET, a u reszty metod (np. POST) zostawiam notimplementedexception?


@grap32:

Nie za bardzo rozumiem, chcesz wystawiać metody/endpointy, które tylko mają coś zwracać? Np. GetBook(int id)?
Jeśli tak to nie widzę sensu tworzenia metod dla POSTów w ogóle
@lol3pdg: kiedy mój problem ubrałem w słowa to okazało się, że sprawa jest o wiele prostsza :) Miałem na myśli implementacje repository pattern dla encji słownikowej. teraz już wiem, że nie tworze nadmiarowego kodu, tylko to czego potrzebuje, w tym przypadku FindByCondition