Ocena pierwszego API (Dziennik elektroniczny)

0

Witam
Przychodzę do was z moim kolejnym projektem do oceny.
Jest to API Dziennika Elektronicznego
https://github.com/daniel500013/school_diary.api

Po ocenie dwóch poprzednich projektów próbowałem zastosować się w większości do rad, które mi daliście (choć na pewno jest coś, co ominąłem albo zapomniałem) jednak mam nadzieje, że tutaj też mi wskażecie moje błędy, bo wiem, że projekt na pewno da się napisać lepiej.

Osobiście mam kilka spostrzeżeń, co do których sam nie jestem pewien do końca więc mam nadzieje, że podpowiecie mi czy idę we właściwym kierunku, czy nie.
Dokładnie to chodzi mi o:

  • Nazewnictwo w kontrolerach (Chodzi mi o to nazewnictwo przy atrybucie Route)
  • Autoryzacja (Chodzi mi tutaj czy optymalnie wykorzystuje atrybut Authorize)

Samo api udało mi się w miarę szybko napisać w ~7 dni może trochę mniej jednak chciałbym zaznaczyć, że w większości siedziałem nad tym projektem od 12:00-4:00 niektórym może będzie wydawało się to dziwne, ale z racji, że aktualnie nie pracuję to mam sporo wolnego czasu.

Projekty te pisze między innymi dlatego, że chce rozwijać swoje umiejętności, ale nie będę ukrywał, że też bardzo bym chciał się dostać na jakieś stanowisko juniora jeżeli chodzi o backend w .net dlatego jeżeli macie jakiś pomysł albo sugestie co można by rozwinąć w tym projekcie, żeby jakoś się wyróżniał to chętnie wysłucham :)

5
  1. Brak testów.
  2. Nazwy klas, metod i właściwości zapisujemy wielką literą, tak każe obyczaj.
  3. var emailValidation = new EmailAddressAttribute().IsValid(user.email); Takie rzeczy lepiej trzymać w dto/viewmodelu jako atrybut.
  4. Brak DTO.
9

Moim zdaniem POST /api/Approve/add, PUT /api/Approve/change/{id} oraz DELETE /api/Approve/delete/{id} są średnie.

Albo bym zrobił żeby wszystko było jedną metodą, albo zmienił nazwy na takie: POST /api/Approve, PUT /api/Approve/{id} i DELETE /api/Approve/{id}. Po co w pathie określenie, skoro można to rozróżnić po metodzie?

Noi Dependency Inversion też złamane, czyli logika rozsiana po klasach, i pomieszane warstwy ze sobą. Nie - zrobienie plików Controller,Service i Model nie liczy się jak dobre rozdzielenie.

0

@Riddle:

  • Wielkie dzięki jeżeli chodzi o te nazwy faktycznie gdy teraz o tym pomyśle to bez sensu było dawać takie nazwy, jakie ja dałem, ale nie wiem czemu wcześniej byłem przekonany, że jak będą takie same nazwy to będzie błąd, ale przecież można rozróżnić po metodzie więc my bad zaraz zabiorę się do poprawiania
  • A co do tego dependency Inversion to nie bardzo rozumiem czy jeżeli w serwisach dodałbym interfejsy to by było wszystko w porządku, czy raczej niezbyt 😅? Jeżeli nie to mógłbyś podesłać jakiś link do artykułu, który by mi pokazać mniej więcej co i jak? Ewentualnie jakiś prosty przykład jeżeli to nie problem 😅😅
6
Kokoniłaj napisał(a):
  1. Brak testów.
  2. Nazwy klas, metod i właściwości zapisujemy wielką literą, tak każe obyczaj.
  3. var emailValidation = new EmailAddressAttribute().IsValid(user.email); Takie rzeczy lepiej trzymać w dto/viewmodelu jako atrybut.
  4. Brak DTO.

W sumie żadna z uwag nie jest kluczowa. Słuszne są jedynie w pewnych sytuacjach ale ciężko je nazwać ogólnymi.
Jak zwykle koncentracja uwagi skierowana jest na to JAK ZOSTAŁO napisane a nie CO ZOSTAŁO NAPISANE.

Moja uwaga jest jedna - brakuje projektu lub dokumentacji. Autor przedstawia kod "CZEGOŚ".
Niby w readme jest jakiś screen ale tylko z nagłówkami funkcji... oraz teksotowy bardzo ogólny zarys planowanej funkcjonalności ale wg mnie to pozostawia zbyt szeroką możliwość interpretacji tego jak ma wyglądać poprawna implementacja API.

Skoro już mamy narysowane ERD to teoretycznie można już stworzyć jednoznaczną dokumentację tego jakie funkcje będzie miał system oraz to jakie będą miały wejście i wyjście nie pozostawiając miejsca na domysły. Zatem ...

ad 1.Ciężko napisać testy w sytuacji kiedy nie wiemy co i jak testować. Jak będzie jednoznaczna dokumentacja będzie można pisać testy. Teraz to bez sensu.
ad 2. Pierdoła. Jedni zapisują tak inni inaczej. Uwaga o tak małej wadze, że nie wiem czy w kontekście dużo większych problemów projektu warto w ogóle o tym wspominać.
ad 3. j.w.
ad 4. Potrzebą zastosowania dodatkowej warstwy można ocenić po tym jak będą znane wszystkie założenia projektu. Mnożenie dodatkowych warstw nie zawsze ma sens i nie zawsze ułatwia choć w większości przypadków nie zaszkodzi. Nie jest to jednak błąd.

Wracając do podstaw - czyli bazy danych... Czy ktoś z komentujących na to w ogóle zerknął?
Przecież ono nie ma sensu... a jak baza jest bez sensu to nie ma mowy o dalszym pisaniu API, które ma z nią współpracować.
W prawie każdej tabeli brakuje kuczy obcych lub są tak ponazywane, że zupełnie nie wiadomo co.
Ogólnie ta baza wymaga ponownego głębokiego przemyślenia i dopiero gdy tu będzie wszystko miało sens będzie można zasiąść do zaprojektowania funkcjonalności API.

screenshot-20220629194607.png

Wg mnie na chwilę obecną autor z tym projektem jest w głębokim lesie (góra mierny tak żeby nie robić krzywdy i przepchnąć do następnej klasy mając z tyłu głowy, że i tak z tego nic nie będzie.
Jeśli ma coś być to trzeba zacząć od początku czyli od:

  1. Szczegółowego rozpisania założeń i funkcjonalności systemu (alternatywą jest kompletny projekt UML ale to raczej mała rzecz więc przy dobrym opisie i bez tego się obejdzie);
  2. Zamodelowania bazy danych;
  3. Rozpisania funkcji API ( wej. / wyj.)

i dopiero wówczas można odpalać Visual Studio... a nie odwrotnie jak to miało miejsce w przypadku powyższego dzieła.

6
katakrowa napisał(a):

ad 2. Pierdoła. Jedni zapisują tak inni inaczej. Uwaga o tak małej wadze, że nie wiem czy w kontekście dużo większych problemów projektu warto w ogóle o tym wspominać.

Czy ja wiem, czy pierdoła. Jak ktoś zobaczy w projekcie .NETowym namespace'y pisane snake casem, to raczej zapali mu się czerowna lampka co do poziomu autora. Może lepiej podpiąc i skonfigurować sobie jakieś analizatory kodu typu StyleCop?

Wracając do podstaw - czyli bazy danych... Czy ktoś z komentujących na to w ogóle zerknął?
Przecież ono nie ma sensu... a jak baza jest bez sensu to nie ma mowy o dalszym pisaniu API, które ma z nią współpracować.

Dość kontrowersyjne podejście w tych czasach :P

1
nobody01 napisał(a):
katakrowa napisał(a):

ad 2. Pierdoła. Jedni zapisują tak inni inaczej. Uwaga o tak małej wadze, że nie wiem czy w kontekście dużo większych problemów projektu warto w ogóle o tym wspominać.

Czy ja wiem, czy pierdoła. Jak ktoś zobaczy w projekcie .NETowym namespace'y pisane snake casem, to raczej zapali mu się czerowna lampka co do poziomu autora. Może lepiej podpiąc i skonfigurować sobie jakieś analizatory kodu typu StyleCop?

Tak jak mnie w przypadku kiedy ktoś podczas oceny zwraca uwagę na nieistotne drobiazgi nie dostrzegając, że podstawy projektu nie istnieją.
Zostaje przy zdaniu, że w tym projekcie wielkości liter to jeden z najmniejszych problemów.

Wracając do podstaw - czyli bazy danych... Czy ktoś z komentujących na to w ogóle zerknął?
Przecież ono nie ma sensu... a jak baza jest bez sensu to nie ma mowy o dalszym pisaniu API, które ma z nią współpracować.

Dość kontrowersyjne podejście w tych czasach :P

Tak? To jakie podejście reprezentuje tutaj autor.
Nie wychodzi ani od bazy ani od interfejsu ani od dokumentacji. Także jeśli wiesz proszę wyjaśnij mi gdzie szukać tu punktu odniesienia?
Autor zamieścił natomiast w repozytorium "strzępy dokumentacji", screen ze swaggera i "skopane ERD" (wyglądające na najbardziej kompletne)...

0
katakrowa napisał(a):

Tak jak mnie w przypadku kiedy ktoś podczas oceny zwraca uwagę na nieistotne drobiazgi nie widząc, że pod strawy projektu nie istnieją.

Tylko że problemy z nazewnictwem, to pierwsza rzecz, jaką zauważy osoba przeglądająca kod, a pierwsze wrażenie jest bardzo ważne i może zdecydować o wielu rzeczach, w tym o tym, czy w ogóle ktoś będzie chciał przeglądać dalej kod. Oczywiście ktoś może przechodzić z innego języka i nie wiedzieć, jakie są konwencje.

Tak? To jakie podejście reprezentuje tutaj autor.
Nie wychodzi ani od bazy ani od interfejsu ani od dokumentacji. Także jeśli wiesz proszę wyjaśnij mi gdzie szukać tu punktu odniesienia?
Autor zamieścił natomiast w repozytorium "strzępy dokumentacji" i "skopane ERD".

Nie pisałem nigdzie o podejściu, które reprezentuje autor. Po prostu w tych czasach popularnych jest wiele podejść, w których projektowanie bazy wcale nie jest na początku.
Jeśli robimy DDD, to przed modelowaniem bazy jest modelowanie domeny.
Jeśli robimy TDD, to zanim zaprojektujemy bazę piszemy odpowiednie testy.
A nawet jeśli nie mamy ani TDD, ani DDD, to też bym nie zaczynał od bazy. Zacząłbym od zaprojektowania encji POCO, a potem stworzył tabele.

2
nobody01 napisał(a):

Tylko że problemy z nazewnictwem, to pierwsza rzecz, jaką zauważy osoba przeglądająca kod, a pierwsze wrażenie jest bardzo ważne i może zdecydować o wielu rzeczach, w tym o tym, czy w ogóle ktoś będzie chciał przeglądać dalej kod. Oczywiście ktoś może przechodzić z innego języka i nie wiedzieć, jakie są konwencje.

Wg mnie to podejście osób, które robią co wiedzą zamiast wiedzieć co robią :-) Przez ostatnie 30 lat "mody" i konwencje na to jak nazywać zmienne i klasy w tym czasie zmieniały się z 10 razy i to o 180 stopni. To nie jest istotne z punktu widzenia poprawności projektu. To jedynie nieformalne wytyczne ułatwiające tworzenie standardowego kodu. Przy błędach, które są w projekcie autora to najmniejszy problem. Przestawienie się w pisaniu między jedną a drugą konwencją to 3 minuty. Wg mnie na etapie nauki to pierdoła.

Nie pisałem nigdzie o podejściu, które reprezentuje autor. Po prostu w tych czasach popularnych jest wiele podejść, w których projektowanie bazy wcale nie jest na początku.
Jeśli robimy DDD, to przed modelowaniem bazy jest modelowanie domeny.
Jeśli robimy TDD, to zanim zaprojektujemy bazę piszemy odpowiednie testy.
A nawet jeśli nie mamy ani TDD, ani DDD, to też bym nie zaczynał od bazy. Zacząłbym od zaprojektowania encji POCO, a potem stworzył tabele.

Ja też nigdzie nie napisałem żeby zacząć od bazy - jedynie zasugerowałem kolejność widząc, że w przesłanych przez autora materiałach ERD wygląda na najbardziej kompletne.
Poza tym zgodzę się z Twoim podejściem jeśli w kolejnym poście uda Ci się wytłumaczyć autorowi == początkującemu programiście co to DDD i TDD.

0

@katakrowa:

  • Dokumentacji faktycznie w projekcie nie ma co oczywiście jest rzeczą niedopuszczalną więc mogę tylko przeprosić i powiedzieć, że dodałem opisy do nagłówków funkcji i mam nadzieje, że teraz to wygląda to trochę lepiej niż wcześniej. Jednak chciałbym zaznaczyć, że tak jak w tytule napisałem jest to moje pierwsze api więc jeżeli nadal będą jakieś niedociągnięcia związane z opisami funkcji to bardzo bym prosił, abyś mi powiedział czego jeszcze brakuje w dokumentacji albo ewentualnie podesłał jakiś link, w którym ktoś tłumaczy jak się piszę dobrą dokumentację bo tak jak wspomniałem jest to pierwsze api i mogło mi bardzo wiele rzeczy umknąć
  • Co do mojej bazy danych to chodziło bardziej o to, że ona ogólnie jest bez sensu czy chodziło ci tylko o klucze obce? Bo jeżeli chodzi o klucze obce to faktycznie tutaj również mogę powiedzieć, że jest mój błąd, ponieważ faktycznie mogłem dodać przedrostek FK do kluczy obcych, aby to było bardziej widoczne. Na obecną chwilę jedynie poprawiłem diagram, żeby bardziej uwidocznić relacje między tabelami. Ale postaram się też pododawać te przedrostki, żeby wszystko było bardziej klarowne. Zdjęcie z bardziej widocznymi połączeniami z tabelami podsyłam poniżej
    image

EDIT:
Co do założeń samego projektu chciałem aby api miało takie funkcje:

  • Uwierzytelnianie użytkowników
  • Autoryzacja rolami
  • Zarządzanie rolami
  • Zarządzanie lekcjami
  • Zarządzanie ocenami
  • Zarządzanie klasami
  • Zarządzanie pochwałami
  • Zarządzanie obecnościami
1

ERD tabela role co to jest id? Klucz obcy czy identyfikator roli?

daniel500013 napisał(a):

Co do założeń samego projektu chciałem aby api miało takie funkcje:

  • Uwierzytelnianie użytkowników
  • Autoryzacja rolami
  • Zarządzanie rolami
  • Zarządzanie lekcjami
  • Zarządzanie ocenami
  • Zarządzanie klasami
  • Zarządzanie pochwałami
  • Zarządzanie obecnościami

Co to jest funkcja "Zarządzanie rolami" ?

  1. Co ma robić?
  2. Jak się ma nazywać?
  3. Jakie ma mieć parametry wejściowe
  4. Jakie będą jej parametry wyjściowe?
  5. i co najważniejsze... wątpię, że to ma być jedna funkcja...

Natomiast "Autoryzacja rolami" to coś całkowicie bez sensu. Albo użytkownik się autoryzuje i ma jakieś uprawnienia określone przez role albo wymyślasz jakiegoś potwora.

Z pozostałymi to samo. Tu brakuje koncepcji, nie ma żadnej informacji jak to ma działać. To także rzutuje na to, że nie mam pojęcia czy w ERD są tylko klucze niejasne czy być może w ogóle nie ma ono sensu.

Zacznijmy od pierwszego punktu "Uwierzytelnianie użytkowników"...
Jak będzie się nazywała funkcja, która za to odpowiada? Będzie osobna?
Jeśli osobna to co będzie mieć na wejściu a co na wyjściu?

A może autoryzacja będzie leciała przy każdym zapytaniu do API zamiast osobnej funkcji?
Jak chcesz zrealizować to logowanie?

0

@katakrowa:

katakrowa napisał(a):

ERD tabela role co to jest id? Klucz obcy czy identyfikator roli?

Tutaj po raz kolejny wychodzi moje niezrozumiałe nazewnictwo kluczy w tabelach co postarałem się po raz kolejny poprawić zdjęcie podsyłam poniżej
image
Usunąłem też jedną relację przy tabeli grades i mam nadzieje, że teraz wygląda to, chociaż odrobinę lepiej niż było to na początku

Co to jest funkcja "Zarządzanie rolami" ?

Co ma robić?
Jak się ma nazywać?
Jakie ma mieć parametry wejściowe
Jakie będą jej parametry wyjściowe?
i co najważniejsze... wątpię, że to ma być jedna funkcja...

Aby wszystko było łatwiejsze do sprawdzenia postanowiłem wstawić statyczną stronę używając swaggera (z użyciem pliku json) i tam opisać większość funkcji (Swagger znajduję się również w głównym projekcie w razie czego)

Link do swaggera

0
daniel500013 napisał(a):

@katakrowa:

katakrowa napisał(a):

ERD tabela role co to jest id? Klucz obcy czy identyfikator roli?

Tutaj po raz kolejny wychodzi moje niezrozumiałe nazewnictwo kluczy w tabelach co postarałem się po raz kolejny poprawić zdjęcie podsyłam poniżej

Teraz wygląda na to, że użytkownik może mieć tylko jedną rolę. Czyli może być uczniem albo nauczycielem albo administratorem. Czy zakładasz, że nie będzie mógł być nauczycielem i administratorem?
Tak właściwie to po co tabela role skoro mamy relację 1:1 z tabelą user? Nie miało to być przypadkiem 1 do wiele?
Wg mnie w tabeli role powinieneś mieć pola:

  • idRole
  • idUser (klucz obcy)
  • name

ewentualnie jeśli ma być 1:1 to nazwę roli trzymaj w tabeli user.

A najlepiej byłoby gdyby tabela role była tylko listą możliwych ról i powiązać je z użytkownikami tabelą asocjacyjną userRole z polami:

  • idUserRole
  • idUser
  • idRole

Dopóki nie masz ogarniętego tego fragmentu to błędów w pozostałych tabelach nawet nie opisuję bo wygląda na to, że póki co masz problem z tworzeniem i rozróżnianiem relacji 1:1, 1:n i n:n...
Gdybyś miał opis słowny tego jak ma działać system to byś wiedział jaką relacją ma być powiązany użytkownik z rolami... Tymczasem twoje działania wyglądają na zgadywanie lub improwizację a nie przemyślane kroki wynikające z realizacji przemyślanej koncepcji.

2
katakrowa napisał(a):

Wg mnie to podejście osób, które robią co wiedzą zamiast wiedzieć co robią :-) Przez ostatnie 30 lat "mody" i konwencje na to jak nazywać zmienne i klasy w tym czasie zmieniały się z 10 razy i to o 180 stopni.

Konwencje w C# są stałe od ponad 20 lat. Jeśli ktoś pisze niestandardowo, to to się od razu rzuca w oczy.
Zwłaszcza, że tu nie ma spójności nawet w ramach tego samego projektu.

To nie jest istotne z punktu widzenia poprawności projektu. To jedynie nieformalne wytyczne ułatwiające tworzenie standardowego kodu. Przy błędach, które są w projekcie autora to najmniejszy problem. Przestawienie się w pisaniu między jedną a drugą konwencją to 3 minuty. Wg mnie na etapie nauki to pierdoła.

3 minuty, jak ktoś jest doświadczony. Jak ktoś od początku nasiąknie niechlujstwem, to mu zostanie.

Co do kodu oprócz konwencji, to:

  1. Nadużywanie Exception w serwisach. Jeśli argument jest null, to rzucamy ArgumentNullException. Jeśli jest spoza zakresu to ArgumentOutOfRangeException. Jeśli coś innego to ArgumentException. Nigdy nie rzucamy po prostu Exception.
  2. approveService.GetUserApproves(uuid.ToString()); - po co konwertować dobry typ na jakiś dziadowski string? Im mniej stringów tym mniej błędów, bo do stringa można wsadzić wszystko, a jak mamy jakiś konkretny typ, to niekoniecznie. Pisz kod tak, aby był strongly typed, a nie stringly typed.
Riddle napisał(a):

Noi Dependency Inversion też złamane, czyli logika rozsiana po klasach, i pomieszane warstwy ze sobą. Nie - zrobienie plików Controller,Service i Model nie liczy się jak dobre rozdzielenie.

Nie widzę tu pomieszanych warstw, logika siedzi sobie w serwisach, a kontrolery mapują HTTP na logikę.

0
somekind napisał(a):

Konwencje w C# są stałe od ponad 20 lat. Jeśli ktoś pisze niestandardowo, to to się od razu rzuca w oczy.
Zwłaszcza, że tu nie ma spójności nawet w ramach tego samego projektu.

Nigdzie nie piszę, żeby olewać konwencje ale napiszę jeszcze raz, że w przypadku tego projekt to najmniejszy i najmniej istotny problem!

To nie jest istotne z punktu widzenia poprawności projektu. To jedynie nieformalne wytyczne ułatwiające tworzenie standardowego kodu. Przy błędach, które są w projekcie autora to najmniejszy problem. Przestawienie się w pisaniu między jedną a drugą konwencją to 3 minuty. Wg mnie na etapie nauki to pierdoła.

3 minuty, jak ktoś jest doświadczony. Jak ktoś od początku nasiąknie niechlujstwem, to mu zostanie.

Jeszcze gorzej jak nauczy się "ładnie" pisać nie zwracając uwagi na to, że pisze głupoty bez celu i planu.

Na chwilę obecną ten projekt nie ma żadnej podstawy ani punktu odniesienia do, którego można stworzyć jakiekolwiek API i tylko dlatego się czepiam uwag o konwencje czy brak testów.
Jeśli autor się weźmie sensownie za robotę to pewnie i na to przyjdzie odpowiedni moment...

0

@katakrowa:

katakrowa napisał(a):

Teraz wygląda na to, że użytkownik może mieć tylko jedną rolę. Czyli może być uczniem albo nauczycielem albo administratorem. Czy zakładasz, że nie będzie mógł być nauczycielem i administratorem?

W tym wypadku mogę powiedzieć, że tak zakładałem, że użytkownik, który zarejestruję się do bazy będzie mógł mieć dokładnie jedną rolę. Postanowiłem tak zrobić, ponieważ nie do końca wiedziałem, jak w samym kodzie mam przypisać użytkownikowi kilka ról więc postanowiłem wybrać to prostsze dla mnie rozwiązanie co nie oznacza, że nie pomyślałem o tym, że nauczyciel mógłby być na przykład administratorem. Podczas pierwszego generowania tabeli są tam wpisywane role automatycznie a są to między innymi:

  • Student - Może pobierać informację tylko o sobie poprzez podanie swojego uuid, nie ma on uprawnień do wstawiania, modyfikacji oraz usuwania danych z tabeli

  • Teacher - Ma on uprawnienia studenta oraz może dodawać, modyfikować i usuwać dane w tabelach Approve, Grade oraz Mark nie ma on jednak dostępu do dodawania, usuwania oraz modyfikacji ról lekcji i klas

  • Tutor - Ma on uprawnienia studenta oraz nauczyciela a dodatkowo może pobrać informacje o wszystkich pochwałach, oraz pobrać informacje o wszystkich ocenach w klasie i wszystkich lekcjach nie ma on jednak dostępu do dodawania, usuwania oraz modyfikacji ról, lekcji, klas

  • LocalAdmin - Posiada on wszystkie z powyższych uprawnień a dodatkowo może on pobierać wszystkie dane o klasach w szkole, pobierać wszystkie oceny oraz dodawać, usuwać, modyfikować lekcje nie ma on dostępu do zarządzania rolami oraz nie może dodawać, modyfikować i usuwać klas w szkole

  • Admin - Posiada on wszystkie z powyższych uprawnień a dodatkowo może on zarządzać rolami (może dodawać, modyfikować, usuwać i pobierać) oraz dodawać, usuwać, modyfikować klasy

EDIT:
Zakładam tutaj, że Adminem jest jakaś osoba zewnętrzna, która udostępnia dany produkt a LocalAdminem jest na przykład jakiś główny informatyk w szkole lub osoba która najbardziej orientuje się w szkole it

0
daniel500013 napisał(a):

W tym wypadku mogę powiedzieć, że tak zakładałem, że użytkownik, który zarejestruję się do bazy będzie mógł mieć dokładnie jedną rolę.

To po co osobna tabela? Wystarczyło pole w tabeli user.

Postanowiłem tak zrobić, ponieważ nie do końca wiedziałem, jak w samym kodzie mam przypisać użytkownikowi kilka ról (...)

Robisz jakąś funkcję, która sprawdza czy użytkownik ma rolę, która jest potrzebna do wykonania danej akcji... UserHas ( 'Student' ) zwraca true lub false...
Na podstawie tego czy tą rolę ma czy nie podejmujesz odpowiednie kroki: pokazujesz przyciski, budujesz odpowiednie zapytanie SQL itp.. itd...

0

@katakrowa:
Skorzystałem z twoich rad i stworzyłem tabele UserRole oraz poczytałem sobie trochę dokumentacji Microsoftu jak ogarnąć to ogólnie w samym kodzie i aktualnie udało mi się zaimplementować to, że użytkownik może teraz posiadać kilka ról, z czego osobiście się cieszę, ponieważ czuję, że sporo się przy tym nauczyłem. Poniżej wstawiam kolejny zaktualizowany diagram bazy danych. Na samym githubie oczywiście diagram też jest zaktualizowany

image

1
daniel500013 napisał(a):

@katakrowa:
z czego osobiście się cieszę, ponieważ czuję, że sporo się przy tym nauczyłem.

Też się cieszę z Twojego postępu i tego, że moje pisanie nie poszło na marne...
Nauczyłeś się tworzyć relację wiele:wiele ( n:n ) w warstwie bazy danych a "sporo" to jeszcze przed Tobą :-)
Teraz możemy iść dalej.

  1. Jaki fragment rzeczywistego świata ma odzwierciedlać tabela userClass? To ma być klasa, która ma uczniów?
  2. Jaki fragment rzeczywistego świata ma odzwierciedlać tabela lesson? To ma być nazwa przedmiotu takiego jak np. Matematyka? Jeśli tak to powinna mieć jakieś powiązanie z klasą. Zwracaj uwagę na to jaka jest rzeczywistość. Projektując encje, obiekty, czy tabele dobrze aby swoją strukturą miały one odzwierciedlenie w rzeczywistości?

Czym jest lekcja (jako encja)?
Jedna lekcja to godzina gadania nauczyciela na temat jakiegoś przedmiotu do stada baranów/uczniów chodzących do jednej klasy...
Widać, że wyłaniają nam się z tego zdania aż 4 encje.
Widać zatem, że ani Twoje userClass ani lesson rzeczywistości nie odpowiadają.

Przemyśl sobie także kolejne zdanie: Podczas lekcji nauczyciel wystawia oceny baranom/uczniom do których po zalogowaniu mają wgląd rodzice.

Podpowiem Ci, że tabela user lepiej gdyby nazywała się person ale to nie ma dużego znaczenia. Pozostańmy przy user ale wiedząc, że każda osoba (aktor) to user.
Zatem userem mogą u nas być:

  • administrator
  • nauczyciel
  • uczeń
  • rodzic

Przemyśl sobie te wszystkie informacje i zaproponuj jak mogłyby wyglądać następujące tabele (tu podpowiedź, że takie powinny istnieć):

  • subject (przedmiot)

Warto też zwrócić uwagę na to, że lesson nie jest nam do niczego potrzebne bo z punktu widzenia dziennika i roku szkolnego nie ma znaczenia na jakiej konkretnie lekcji ocena została wystawiona uczniowi. Chyma, że użyjemy lekcji "ogólnie" mając na myśli wszystkie ich wystąpienia w semestrze jako jeden rekord po to by powiązać przedmiot z klasą i nauczycielem.

Pozostawiam do przemyślenia... i wciąż nie ukrywam, że łatwiej by było najpierw wiedzieć co ma robić system a potem projektować elementy a nie projektować w ciemno.

0

@katakrowa:
Po kilku dniach nieobecności wracam, aby podzielić się moimi poczynaniami.

  • Postanowiłem tym razem nie wykonywać wszystkich operacji na
    istniejącej bazie danych tak jak wcześniej to robiłem tylko użyć do tego programu, który pozwala
    tworzyć diagram bez konieczności tworzenia bazy danych a poniżej jest efekt tego
    mam nadzieje, że teraz logiczniej to wygląda

image

Mam też inna wersje, ponieważ wydaje mi się, że tabela approve, czyli pochwały mogłaby tu też się sprawdzić, ponieważ uczeń dostaje pochwałę w trakcji realizacji tematu, ale to już pozostawiam do oceny
bo możliwe, że się mylę

image

NN obok typów zmiennych oznacza jeżeli dobrze rozumiem not null przynajmniej ja to tak rozumiem.
Być może jest to oczywiste lub nie ale wole wspomnieć, aby nie było niedopowiedzeń

  • Dobrze spróbuję opisać, jakie są moje założenia dotyczące tego projektu jednak
    chce zaznaczyć, że nie mam w tym dużej wprawy więc w razie czego proszę, aby zadawać pytania jak czegoś
    nie dopowiedziałem albo jak coś jest niejasne

Założenia:

  • Użytkownik będzie mógł się rejestrować do bazy danych za pomocą api oraz będzie
    miał możliwość logowania za pomocą tokena JWT, w którym będą przechowywane
    dane takie jak: długość sesji, role użytkownika (może mieć ich kilka), swój unikalny identyfikator (uuid)
  • Dziennik ma pozwalać na dodawanie, usuwanie, modyfikacje lekcji takich jak: Matematyka, Polski, Angielski.
    Funkcja ta ma być możliwa tylko i wyłącznie dla użytkownika z rolą Admin. Nauczyciel nie ma dostępu do żadnej z powyższych możliwości
  • Dziennik ma posiadać funkcjonalność, aby dodawać, modyfikować oraz usuwać oceny przez nauczyciela (rangi wyższe od nauczyciela również powinny mieć taką możliwość). Użytkownik, który będzie posiadał
    uprawnienia rodzica powinien mieć możliwość wglądu w oceny swojego dziecka.
  • Dziennik ma posiadać możliwość dodawania, usuwania i modyfikowania klas w szkole. Dziennik powinien on również pozwalać na przydzielanie uczniów do poszczególnych klas. Tylko Admin może wykonywać te akcje
  • Dziennik powinien mieć funkcje pochwał dla ucznia na danej lekcji. Pochwały nadaje nauczyciel (rangi z wyższymi uprawnieniami również mają taką możliwość)
    na określonej lekcji. Pochwały można dodawać, modyfikować oraz usuwać
  • Dziennik ma posiadać możliwość dodania obecności na określonej lekcji.

Oczywiście każda funkcja typu dodawanie, modyfikowanie lub usuwanie będzie posiadała nazwy w stylu Add{nazwa funkcji, która chcemy utworzyć}, Get{...}, Put{...}, Delete_{...}
a parametrami to będą w większości albo uuid danego użytkownika jeżeli będziemy chcieli pobrać coś z bazy danych związanego z tym użytkownikiem, albo id
danego rekordu w określonej tabeli, która chcemy Zmodyfikować, Usunąć

3

Nie chciałbym żebyś był zawiedziony ale nie bardzo chce mi się prowadzić Cię za rękę podczas całego procesu projektowania :-)
Oczywiście rozumiem, że czyjaś pomoc jest łatwiejsza niż samodzielne sięgnięcie do odpowiedniej książki ale myślę, że mając punkt zaczepienia mógłbyś właśnie tam szukać odpowiedzi na dalsze pytania.

Choć jest już lepiej to nadal uważam, że Twoje założenia są zdecydowane zbyt ubogie i nadal nie determinują jednoznacznie co ma robić system. Brakuje w tym systematyki. To nadal tylko zbiór niepoukładanych myśli.

Dziennik ma pozwalać na dodawanie, usuwanie, modyfikacje lekcji takich jak: Matematyka, Polski, Angielski.

Lekcji czy przedmiotów?

Funkcja ta ma być możliwa tylko i wyłącznie dla użytkownika z rolą Admin. Nauczyciel nie ma dostępu do żadnej z powyższych możliwości

A co jak nadamy nauczycielowi rolę Admin?

Dziennik ma posiadać funkcjonalność, aby dodawać, modyfikować oraz usuwać oceny przez nauczyciela (rangi wyższe od nauczyciela również powinny mieć taką możliwość).

Gdzie te "rangi" są zdefiniowane? Jakie są te rangi?

Dziennik ma posiadać możliwość dodawania, usuwania i modyfikowania klas w szkole.

Co to jest klasa i co znaczy modyfikować klasę?

...
...

Projektując to wyjdź od rzeczywistości... Będzie łatwiej.

  • jak wygląda dziennik
  • co w nim jest ( strony ... i co jest na tych stronach )
  • do czego przypisany jest dziennik.
  • itp.. itd ...
0
daniel500013 napisał(a):

Ło panie, porwałeś się z motyką na słońce.
Jako były belfer i admin dziennika elektronicznego mogę spokojnie stwierdzić, że dla początkującego to jest zbyt trudny temat.
Żeby taki dziennik miał sens (również tylko jako portfolio) musiałbyś go mocno rozszerzyć.
Ja akurat wdrażałem i administrowałem tym:
Znam ten dziennik na wylot i nie wiem czy potrafiłbym go napisać tak jeden do jeden. Wydaje się mocno skomplikowany. Ale te wszystkie funkcjonalnośći są tam potrzebne. Inaczej dziennik nie ma sensu.

Tak jak @katakrowa napisał, taki system trzeba mocno przemyśleć.

Tak na szybko:

  1. Dane szkoły
  2. Nazwy przedmiotów, (skróty, nazwy na świadectwie, nazwy w arkuszu ocen),
  3. Plan lekcji
  4. Definicje godzin lekcyjnych i przerw
  5. Dni wolne od zajęć
  6. Zastępstwa,
  7. Oddziały klas,
  8. Podział na grupy (dynamiczny)

I jeszcze od groma innych rzeczy.
Serio, to jest cięzki temat.

0

@szydlak:
Oczywiście mam świadomość, że taki dziennik to jest skomplikowana sprawa jednak postanowiłem kompletnie przebudować ten dziennik, który tutaj wstawiłem (mam już zrobiony kompletnie nowy projekt pod to) i mam sporo funkcjonalności już w nim zrobionych. Aktualnie robię do niego frontend więc może za 3-4 dni lub później w zależności ile rzeczy będzie sprawiało mi trudności w frontendzie dam link do nowego projektu w tym temacie i sami ocenicie, choć wiem, że będzie miał sporo niedoskonałości to chciałbym, żeby chociaż w cv ten projekt wyglądał na tyle dobrze, że mógłbym się wyróżnić na tle innych juniorów.

0

@somekind:
@szydlak:
@katakrowa:
Trochę czasu już minęło odkąd założyłem ten wątek, ale niestety frontend sprawił mi sporo trudności, a jednak chciałem, żeby jakoś to wyglądało 😅 czy mi się udało nie wiem dlatego piszę do was, abyście mogli sprawdzić jak bardzo moje umiejętności się poprawiły (przynajmniej te w c# bo angulara niewiele używałem dlatego nie spodziewam się, aby to było jakoś super napisane).

Co do samego projektu to postanowiłem napisać go kompletnie od nowa, ponieważ poprawianie istniejącego już projektu zajęłoby mi zbyt wiele czasu. Link do nowej wersji projektu podsyłam poniżej
Link do projektu

Na końcu chciałbym jednak zaznaczyć, że ten projekt nie ma i nigdy nie miał być przeznaczony do szerszego użytku. Napisałem go bardziej z tego powodu, że chciałem sobie wpisać coś ciekawego do cv niż standardową todo listę (której oczywiście nie umniejszam, bo wielu rzeczy można się przy niej nauczyć) dlatego też bym prosił was o wyrozumiałość

Czekam na uwagi z waszej strony :D

0

Dlaczego nie masz w repo .gitignore?

0
west napisał(a):

Dlaczego nie masz w repo .gitignore?

Już dodałem :)
Nie wiedziałem wcześniej i zresztą nie miałem potrzeby używania .gitignore, ale po doinformowaniu się dodałem i usunąłem według mnie zbędne elementy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1