MVC, DAO i dobre praktyki na start.

Jest koniec marca, więc miesiąc pracy za mną. Co w tym czasie osiągnąłem? Przede wszystkim zamodelowałem wstępnie system. Znam jego podstawowe klasy (diagram klas jeszcze się pojawi), działania jakie wywoływać będą odpowiedni użytkownicy, oraz gdzieś tam w głowie kształtuje mi się wygląd systemu. Mam również trochę kodu! I tutaj proszę o wybaczenie, ale nie ogarnąłem jeszcze gita. Muszę doczytać o nim dokladniej, o .gitignore, gdzie wrzucić polecenie SQL creation tak, żeby innym baza działała, itp. Postaram się to zrobić w miarę szybko, żeby był wgląd do kodu na bieżąco.

Aplikację 99CRM od początku chciałem zbudować opierając na dobrych praktykach programistycznych. Jeśli od początku aplikacja powstaje zgodnie ze sztuką programistyczną, to nawet gdyby jej złożoność była ogromna, pozwoli ona w łatwy sposób wprowadzić zmiany bez wielkiego nakładu  pracy programisty. Czasem sprawia mi to problem, bo zamiast kodować przez kilka dni studiuję dany wzorzec, żeby później wdrożyć go u siebie. No ale tak już mam.

MVC – Model View Controller, czyli rozdzielenie każdej z warstw aplikacji. Nawet na studiach udało się profesorom o tym wspomnieć. View odpowiada za wygląd, odbieranie i przekazywanie instrukcji z/do Controllera. View jest widokiem użytkownika, odpowiada za interakcję z nim, odbiera od niego dane, komendy, żądania itp. Controllera zadaniem jest weryfikowanie ządań View, i interakcja z modelem. Przetwarza żądania widoku i składa zapytanie do modelu. Przykład?:
W widoku użytkownik zażądał usunięcia kontrachenta o id=2.
View: „Hej controller. użytkownik właśnie zażądał usunąć kontrahenta 2.”
Controller: „Ok. ten użytkownik może usuwać. Model. Trzeba usunąć kontrahenta 2″
Model:” Ok Controller. Usuwam kontrahenta 2. Usunięty.”.
Controller:”Świetnie. View, przesyłam Ci nową listę kontrahentów.”
View:”Super. Pokarzę ją użytkownikowi.”

To krótka historyjka pokazująca jaki jest główny zamysł stosowania MVC. Separacja zadań. Podobnie jak w pracy, gdzie każdy z pracowników ma swoje obowiązki, odbiera żądania, i realizuje je korzystając z pomocy innych pracowników, firm zewnętrznych itp. Nikt z reguły nie wychodzi poza obszar własnego zakresu obowiązków.

DAO – Data Access Object – jest obiektem w aplikacji, który pełni rolę pomostu między aplikacją a źródłem danych. Czestą łączony jest z modelem MVC. Obiekt ten separuje instrukcje służące do manipulacji danymi pomiędzy aplikacją a źródłem danych, np bazą danych. Pozostała część aplikacji nie ma pojęcia w jaki sposób przechowywane są dane, co robią instrukcje, które wywołujemy w celu aktualizacji danych. Jak w samochodzie, dodajesz gazu i oczekujesz, że samochód zwiększy obroty silnika i prędkość. Nie musisz wiedzieć, że należy zwiększyć dawkę paliwa podaną do silnika, regulować dopływ powietrza itp. Podobnie jest z DAO – obiekt otrzymuje komendę addStudent() i ma ją wykonać lub zwrócić błąd. Nie wiesz co dzieje się w środku, jakie zapytanie zostało wysłane do bazy – tym zajmuje się DAO. Separacja po raz kolejny.

Równolegle do tworzenia aplikacji, wertuję strony książki CZYSTY KOD. PODRĘCZNIK DOBREGO PROGRAMISTY„, Autor: Robert C. Martin. Tytuł brzmi bardzo zachęcająco 🙂 Autor, wykorzystując swoje kilkudziesięcioletnie doświadczenie jako programista, opisuje dobre praktyki podczas tworzenia oprogramowania. M.in. porusza kwestię nazewnictwa klas, metod, zmiennych i pokazuje zagrożenia, jakie niesie ze sobą złe nazewnictwo obiektów. Sprawdziłem to w praktyce. Otworzyłem jedną z mini aplikacji, którą stworzyłem na studiach, gdzie nie było żadnych komentarzy do kodu. Nazwy zmiennych często nie określały ich przeznaczenia. Niezbędna była głęboka analiza kodu, zanim zorientowałem się co wykonuje aplikacja.
Dlatego w 99CRM staram się stosować nazewnictwo jasno opisujące funkcję danego obiektu. Na przykład podam często wykorzystywane zmienne lokalne, int a, b, x, y, których roli w systemie, na pierwszy rzut oka nie jesteśmy w stanie okresli, jeśli obok nie zamieścimy komentarza. A gdy te same zmienne nazwiemy int srednieWynagrdzenie, miesieczneWynagrodzenie, oraz Punkt(int x, int y). Czy teraz linia ze zmiennymi wymaga komentarza? Nie, bo ich nazwy określają, jakie dane przyjmują w systemie.
Podobnie z metodami:
Student gSTBId(int id) – nie do końca wiadomo co jest zadaniem tej metody, ale fakt – jej nazwa jest krótka 🙂
Student getStudentTypeById(int studentId)  – tutaj raczej nie muszę Ci tłumaczyć, co wykonuje metoda,

Dobre praktyki przy tworzeniu aplikacji, to moim zdaniem najważniejsze zasady jakimi programista powinien się kierować. Sam nie jestem mocno doświadczony, ale widzę, że opisane wyżej wzorce i zasady pomagają, pozytywnie wpływają na rozwój kodu i na jego uniwersalność. Polecam.

1 thought on “MVC, DAO i dobre praktyki na start.

  1. Właśnie z tego powodu co piszesz, boję się otwierać programy, które napisałem na początku swojej nauki:) Co do książki „Czysty kod”, w pełni się zgadzam – świetna pozycja i obowiązkowa.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *