Cześć. Przychodzę do Was z drugim projektem (trochę podobnym do poprzedniego, który tutaj wstawiałem) a mianowicie aplikacją do zarządzania codziennymi zadaniami. Opiera się ona o bazę danych, w której widnieją użytkownicy oraz ich zadania. Użyłem pierwszy raz MVC pattern.
Myślałem o tym, by był to mój ostatni projekt bez żadnego frameworka, zamierzam się teraz zabrać za Springa. Dobry pomysł?
Oto link do githuba: https://github.com/must1/ToDoApplication
Dzięki za jakiekolwiek uwagi.
Mam potrzebę wspomnieć o:
AnyKtokolwiek napisał(a):
Mam potrzebę wspomnieć o:
- Użycie slr4j.Logger jako view, poczynając od wyświetlania opcji menu, jest kontrowersyjne. Wręcz zdębiałem jak szukałem View
, slf4j użyłem z tego względu, iż czytałem w necie, że lepiej jest tego użyć aniżeli sys.out. Jest wydajniejsze i ogolnie wg mnie warto sie przyzwyczaić do tego jeżeli chodzi o przyszłe projekty gdzie nie używa sie system.out.
- Podział na foldery, z jednej strony jakby klasyczny i wiele takich przykładów - jednak wymusza strasznie dużo w zakresie dostępu 'public'. Zobacz YT kol. Nabrdalika,
Czy jest to duży błąd? Szczerze powiedziawszy, obejrzałem 20min filmiku i dalej nie wiedziałem co zmienić. Jeżeli chodzi o strukturę plików którą mam teraz, jest ona przejrzysta i wiadomo gdzie co jest, więc jest to na pewno duży plus. Poza tym, chyba w MVC zawsze się tak dzieli?
must napisał(a):
AnyKtokolwiek napisał(a):
Mam potrzebę wspomnieć o:
- Użycie slr4j.Logger jako view, poczynając od wyświetlania opcji menu, jest kontrowersyjne. Wręcz zdębiałem jak szukałem View
, slf4j użyłem z tego względu, iż czytałem w necie, że lepiej jest tego użyć aniżeli sys.out. Jest wydajniejsze i ogolnie wg mnie warto sie przyzwyczaić do tego jeżeli chodzi o przyszłe projekty gdzie nie używa sie system.out.
Owszem, mogłeś czytać, ale artykuł dotyczył rozwiązań do Logowania
must napisał(a):
Czy jest to duży błąd? Szczerze powiedziawszy, obejrzałem 20min filmiku i dalej nie wiedziałem co zmienić. Jeżeli chodzi o strukturę plików którą mam teraz, jest ona przejrzysta i wiadomo gdzie co jest, więc jest to na pewno duży plus. Poza tym, chyba w MVC zawsze się tak dzieli?
Podział na foldery jest kwestią czysto umowną. W filmiku chodzi o to, żeby dzielić zgodnie z funkcjonalnością. Np. stworzyć folder registration gdzie będzie RegistrationController, RegistrationService, używane w tym celu DTO i tak dalej. Dzięki temu gdy pracujesz nad rejestracją to masz wszystkie potrzebne pliki pod ręką, a nie musisz skakać między folderami.
mad_penguin napisał(a):
must napisał(a):
Czy jest to duży błąd? Szczerze powiedziawszy, obejrzałem 20min filmiku i dalej nie wiedziałem co zmienić. Jeżeli chodzi o strukturę plików którą mam teraz, jest ona przejrzysta i wiadomo gdzie co jest, więc jest to na pewno duży plus. Poza tym, chyba w MVC zawsze się tak dzieli?
Podział na foldery jest kwestią czysto umowną. W filmiku chodzi o to, żeby dzielić zgodnie z funkcjonalnością. Np. stworzyć folder registration gdzie będzie RegistrationController, RegistrationService, używane w tym celu DTO i tak dalej. Dzięki temu gdy pracujesz nad rejestracją to masz wszystkie potrzebne pliki pod ręką, a nie musisz skakać między folderami.
Rozumiem, tylko czy jest to duży błąd? Z tego co zrozumiałem, to w filmiku mówił, że jedni robią tak, drudzy tak. Jak już wspomniałem, podział który teraz mam jest bardzo przejrzysty, wiadomo gdzie co jest.
must napisał(a):
Rozumiem, tylko czy jest to duży błąd?
Nie, nie jest to duży błąd. Organizacja plików w projekcie jest w dużej mierze umowna, najważniejsze żeby konsekwentnie trzymać się ustalonej konwencji oraz być świadomym jej wad i zalet.
Prelegent sam zaznaczył (jeżeli zwróciłeś uwagę), że w wielu firmach nie stosuje się ograniczeń dostępu. Podobnie w wielu firmach nie stosuje się testów jednostkowych.
Innymi słowy, jeżeli będziesz miał w projekcie lepszą organizację plików albo pokrycie testami jednostkowymi, to automatycznie możesz w niektórych firmach dostać dodatkowe punkty. Rekruter w takim wypadku może stwierdzić, że warto ciebie zatrudnić, ponieważ możesz wnieść jakąś wartość dodaną do projektu albo będziesz tańszy w szkoleniu (bo już znasz testy i dobre praktyki).
Haskell napisał(a):
must napisał(a):
Rozumiem, tylko czy jest to duży błąd?
Nie, nie jest to duży błąd. Organizacja plików w projekcie jest w dużej mierze umowna, najważniejsze żeby konsekwentnie trzymać się ustalonej konwencji oraz być świadomym jej wad i zalet.
Prelegent sam zaznaczył (jeżeli zwróciłeś uwagę), że w wielu firmach nie stosuje się ograniczeń dostępu. Podobnie w wielu firmach nie stosuje się testów jednostkowych.
Innymi słowy, jeżeli będziesz miał w projekcie lepszą organizację plików albo pokrycie testami jednostkowymi, to automatycznie możesz w niektórych firmach dostać dodatkowe punkty. Rekruter w takim wypadku może stwierdzić, że warto ciebie zatrudnić, ponieważ możesz wnieść jakąś wartość dodaną do projektu albo będziesz tańszy w szkoleniu (bo już znasz testy i dobre praktyki).
Rozumiem w pełni! Zaraz to pozmieniam.
Poza organizacja plików, jakieś uwagi co do samego kodu?
Możecie powiedzieć czy dobrze myślę odnośnie tej struktury.
Mam 3 kontrolery "poboczne". TaskManagementController, RegistrationController, LoginController + do każdego view oraz model. Poza tym mam jeden dodatkowy kontroler ToDoController, który tak jakby zbiera wszystkie pozostałe i łączy w całość.
Tworzę pakunek registration i wpycham w niego kontroler, view oraz model.
Tworze pakunek login i wpycham analogicznie.
Tworzę pakunek taskmanagement i analogicznie jak u góry.
I w osobnym pakunku mam ten dodatkowy kontroler + do niego wygląd.
To skutkuje tym, że pozbywam się słowa public z wyglądu i modelu każdego kontrolera. Jeżeli chodzi o klasy odpowiedzialne za bazę danych, to mam podział na akcje użytkownika i akcję dotyczące zadań (dodaj zadanie, usun, pobierz wszystkie). I klasa UserActions jest używana przez dwa modele dot. logowania i rejestracji. I teraz nie wiem czy wydzielić tę jedną metodę odpowiedzialną za rejestrację i powrzucać te klasy dot. bazy danych do tych folderów, czy pozostawić tak jak jest?
taktyczny rifresz