Aplikacja Klient: WPF Server: .NET Core

Aplikacja do zarządzania zadaniami i taskami. Bardziej pisana dla funu niż po to, by była użyteczna (myślę, że część WPFową można by było rozwinąć i podpiąć pod np. API Jiry ale to takie gdybanie).

https://github.com/michasacuer/TaskManager

Klient został napisany w WPF, zaś API W .NET Core. Wiem, że niektóre rozwiązania są trochę overengineering ale jak czegoś większego bym nie zrobił to bym się nie nauczył. Sugestie co jest źle mile widziane

Szybki rzut okiem - na plus:

1. Użycie MediatR i SignalR.
2. Readme na github
3. Fajne rozbicie architektury na podprojekty

Sugestie/uwagi:

1. https://github.com/michasacuer/TaskManager/blob/master/Src/Web/TaskManager.Api/Controllers/TaskController.cs#L57 - do edycji lepiej/poprawniej użyć PUT (ewentualnie PATCH) i założyć URL typu api/tasks/{taskId}. Taka forma REST-owych endpointów będzie poprawniejsza.
2. Pytanie z ciekawości, dlaczego zdecydowałeś się na dodanie warstwy repozytorium?

Ogólnie ten projekt bardzo na plus pod kątem architektury i jakości kodu :)

Warstwa repozytorium dodana bez celu. Wiem, że datasety EF to repozytoria a context jest unit of workiem. Po prostu chciałem to napisać i mam. W obecnej mecie dobre to nie jest, złe tez jakoś nie specjalnie. Podobała mi się ostatnio zasłyszana idea extensionów w EF, zamiast za każdym razem pisać zapytania linq do datasetów EF używamy napisanych extensionów z których dostajemy odpowiedni model. Wydaje mi się, że może to zwiększyć czytelność

Co do readme sam lubie patrzeć na ładne opisy. Po co ktoś ma ściągać i odpalać kod, zobaczy sobie na gifach jak to się prezentuje. Jedyna wada to to, że te gify są dość duże (po pare mb)

Możesz jeszcze pójść krok dalej i :

1. Pozbyć się anemic domain model,
2. Wyrzucić z domeny referencje do Identity, (Tak, żeby user nie dziedziczył z ApplicationUser), da się :)

po co testować controllery gdy "każdy" z nich ma jeden LoC i leci prosto do handlera? :P