Qt, aplikacja łącząca się z bazą danych ( struktura projektu ).

Question

Witam, piszę dla nauki prosty "symulator" aplikacji pozwalającej na zalogowanie się na konto, dokonywanie na nim zmian oraz zakładanie nowego konta. Pytanie jest bardzo krótkie i dotyczy struktury projektu. 

Po wciśnięciu przycisku zaloguj otwiera się "dialog" z panelem logowania, rzecz jasna z poziomu klasy tego okienka jest już potrzebne połączenie się z bazą danych by sprawdzić poprawność loginu i hasła. Następnie zostanie otwarte nowe okno z widokiem dla zalogowanego użytkownika oraz możliwością modyfikacji jego danych. Oba okna to kompletnie inne od siebie klasy, korzystają one jednak ze wspólnej bazy danych. I tu zastanawiam się nad najbardziej optymalnym ułożeniem wszystkiego w projekcie, np:

-> Mogę w oknie zalogowanego użytkownika na nowo połączyć się z bazą.

-> Umieścić obiekt bazy danych globalnie w jeszcze innym zewnętrznym pliku.

Nie wiem jak to dobrze zorganizować :/

Mam nadzieje że wiecie z czym mam dylemat... w razie pytać proszę pisać to postaram się wytłumaczyć dokładniej. Z góry bardzo dziękuje za radę albo linka do jakiegoś artykułu i pozdrawiam serdecznie :)

 

Answer 1

Zależy. Jak będziesz korzystał z jednej bazy danych w projekcie to zadeklarowanie go globalnie w programie lub w pliku (ze słowem static) nie jest błędem. Natomiast jak potem, po rozbudowie programu, będziesz korzystał z kilku baz, to starych funkcji nie użyjesz ponownie. Jak to mały projekt z jedna bazą, zadeklaruj globalnie. Jak duży i nie wiesz jak będzie rozwijany, to przekazuj obiekt bazy do poszczególnych funkcji. Poza tym w QT chyba była jeszcze pula połączeń, może to Ci pomoże?

Pozdrawiam

Answer 2

Warstwą dostępową do bazy, będzie dedykowana klasa pełniąca funkcję repozytorium. Rezyduje w warstwie obsługi persystencji a Twoje rozterki wynikają w głównej mierze z chęci (nieświadomego) przeskoczenia warstw aplikacji.

Pytasz bo chcesz by było tak: GUI -> DB. A zdrowiej było by tak: GUI -> Logika -> Persystencja -> DB.

W warstwie logiki będziesz miał klasy reprezentujące konto użytkownika, elementy bezpieczeństwa itp... W warstwie Persystencji ukryjesz (choć to nieładne podejście ale aplikacja mała) nawet kod SQL. Z warstwy Persystencji, wystawisz metody zwracające np. obiekt konta na podstawie loginu. GUI wtedy nie będzie interesowała DB a wyłącznie obiekt konta.

Poza tym w Qt masz model Model/View: https://doc.qt.io/qt-5/model-view-programming.html i warto go stosować.

Comments

W warstwie logiki będziesz miał klasy reprezentujące konto użytkownika, elementy bezpieczeństwa itp... W warstwie Persystencji ukryjesz (choć to nieładne podejście ale aplikacja mała) nawet kod SQL.

No, ok. To brzmi logicznie. No ale obiekt reprezentujący konto użytkownika muszę gdzieś umieścić. I o to chodzi w pytaniu, myślę żeby stworzyć go w oknie logowania i przekazać dalej.

---

Możliwa implementacja (nie jedyna):

Uwierzytelnienie:

1. "Okno logowania", odpytuje repozytorium (bezpośrednio lub pośrednio), o poprawność danych do logowania.

2. Metoda repozytorium odpowiada true/false co do poprawności danych.

W wyniku jeszcze nie masz obiektu konta bo to nie jest celem tej procedury

Praca z kontem:

1. Po "zalogowaniu" (poprawnie uwierzytelnieniu), GUI woła repozytorium o kreację obiektu użytkownika o określonym ID.

2. Repozytorium samo sprawdza czy użytkownik jest już obecny (np w swoim cache) i czy dane konta są w bazie. Jeśli procedura kreacji obiektu konta jest złożona, wydzielisz ją do jakieś metody/fabryki/buildera wołanego na poziomie repo a nie logiki aplikacji.

3. Jeśli obiekt konta już jest, jest zwracany (czy z cache czy "świeżo tworzony z bazy" bez lub z pomocą fabryki). Jeśli nie ma, do zamawiającego (w tym przypadku GUI), wędruje informacja o błędzie o braku takiego obiektu.

W wyniku dopiero tu kreowany jest obiekt konta, to on będzie decydował "kiedy się zapisać i czy się zapisać" a repozytorium samo podejmie decyzję jak obsługiwać cache (np. może go po prostu nie mieć i na każde żądanie tworzyć nowy obiekt). To obiekt jak będzie niszczony zleci repo zapisanie swojego stanu. I to w samym obiekcie masz zaimplementować porównanie między nimi ich ID by np. stwierdzić że to to samo konto.

No i teraz... powiedz gdzie masz jakieś przekazywanie? To w warstwie persystencji (czyli repo) podejmujesz jak będzie wyglądał prawdziwy cykl życia obiektu.