Przejrzałem tylko na szybko.
Bardzo fajnie, że wstrzykujesz sobie zależności (serwisy danych) do kontrolerów. To dobra technika.
Dobrze też, że masz wydzielone warstwy w projekcie za pomocą separacji oddzielnymi projektami (API, Services, Data)
Plus za projekt Tests ale minus, że nie ma w nim testów :D
Dobrze, że masz klasy ViewModeli, to dobra praktyka. Nie zaglądałem zbyt wiele w widoki, ale wierzę, że nie jest źle.
Były plusy to teraz uwagi.
Moim zdaniem zależności w takim projekcie powinny być następujące. Api/Front zależy od serwisów, serwisy zależą od danych, koniec. Przebudowałbym to tak, żeby Api nie miało zależności na dane. Po to mamy właśnie podział na warstwy.
Gdyby pojawiło się inne źródło danych to przerabiasz serwisy tak żeby ciągnęły dane z odpowiedniego źródła, a dla warstwy Api te zmiany są transparentne. Zakładając, że pracują nad tym różne osoby i ktoś jest odpowiedzialny tylko za API, nie musi uczestniczyć w tej pracy dostosowując swój projekt do zmian na linii Data -> Services.
Idąc tym tropem pojawia się jeszcze jeden problem. Zauważyłem, że kilka ViewModeli masz w projekcie Data.
Ja jakby rozumiem z czego to wynika. Potrzebujesz zwracać dane do wyświetlenia z bazy i to jest pierwsze rozwiązanie, które podsuwa intuicja.
Przerobiłeś już kwestię Dependency Injection. Pora na kolejny ważny temat, a mianowicie mapowanie danych.
W skrócie chodzi o to, że API powinno mieć swoje modele, serwisy swoje modele, a Data swoje modele, a pomiędzy tymi warstwami dane są mapowane. Można ułożyć to na przykład tak:
API ma ViewModels, serwisy mają Models, a Baza ma DbModels (nazwy przykładowe)
API potrafi mapować dane z ViewModels do Models i odwrotnie. Wszystko co przychodzi do API z Serwisów za pomocą serwisowych metody typu Get powinno przychodzi jako Models, tak samo jak wszystko co wychodzi z API do serwisów w metodach Create czy Set powinno być już przemapowane do Models.
Serwisy natomiast dane Data mapują przed przesłaniem dalej do API z DbModels na Models i odwrotnie, zapisując coś do bazy mapują z Models na DbModels. Można to wszystko robić ręcznie lub użyć np biblioteki AutoMapper i odpowiednio to pokonfigurować. Nie jest to trudniejsze niż konfiguracja Ninjecta więc wiedza na poziomie, nad którym aktualnie pracujesz.
No i te testy jednostkowe na przykład w NUnitcie. Jeśli to ma być projekt wizytówka i chcesz go by był Twoją wizytówką przy szukaniu pracy to na pewno warto to dodać.
Nie wszystko przejrzałem, pisałem dość na szybko i nie jestem wszechwiedzący więc za ewentualne błędy przepraszam ale też starałem się nie pisać jeśli nie byłem czegoś pewny.
Obczaj sobie też temat DTO (Data Transfer Object). Jest bezpośrednio związany z przesyłaniem danych między warstwami ale go nie poruszałem bo dawno nie miałem z nim do czynienia i mógłbym coś pokręcić :)
Wielkie dzięki za możliwość zajrzenia do Twojego kodu. Bardzo fajnie było spojrzeć i mam nadzieję, że pomogłem. Powodzenia i pozdrawiam :)
Bonus:
Chyba nie wgrałeś wszystkich plików na repo. Gdy próbowałem wejść w js'y to dostałem w mordę takim komunikatem:
