RFC użytkownicy i grupy |
RFC użytkownicy i grupy |
7.09.2011, 10:29:10
Post
#1
|
|
Grupa: Zarejestrowani Postów: 7 Pomógł: 0 Dołączył: 18.01.2010 Ostrzeżenie: (0%) |
witam.
chciałbym się dowiedzieć, co sądzicie o takim zaprojektowaniu klas do obsługi użytkowników i grup. będą używać 3 tabel z bazy danych: - users: id, name, hash, email // ([nazwa]:[pola]) - membership: id, uid, gid - groups: id, name będę wdzięczny za jakiekolwiek sugestie
Ten post edytował zajonc 7.09.2011, 10:40:31 |
|
|
7.09.2011, 10:56:22
Post
#2
|
|
Grupa: Zarejestrowani Postów: 664 Pomógł: 169 Dołączył: 8.01.2010 Skąd: Kraków Ostrzeżenie: (0%) |
1) W klasach User i Group masz settery i gettery do każdej wartości, więc jaki jest ich sens? Przypuszczam, że i tak będziesz wysyłał zawsze pełny zestaw danych więc zastanów się nad zastąpieniem tych metod: setData(array $data).
2) W konstruktorze nie powinno być parametru id, bo skąd wiesz jaki id będzie miał rekord? Przypuszczam, że kolumna jest auto inkrementowana. Id powinien być ustawiany dopiero po zapisie User/Group w bazie. 3) Groups i Users powinny rozszerzać klase abstrakcyjną np. TableAbstract, ponieważ w innym wypadku będziesz miał sporo kodu, który będzie duplikował się. 4) Metody add() i remove() powinny przyjmować jako parametr obiekt klasy User/Group, ponieważ to właśnie je chcesz zapisać/usunąć w/z bazy. 5) Czy rzeczywiście jest ci potrzebna metoda exist() ? Zastąpiłbym ją raczej find(), która zwróci albo obiekt (czyli rekord jest) albo false (brak rekordu). 6) Metody check() i hash() z klasy Users powinny wylecieć. check() jest metodą autoryzacji, więc powinna się znaleźć w tego typu klasie, natomiast hash() przypuszczam, że wykonuje jakieś operacje na stringu, więc na to konto również powinna być odpowiednia klasa. -------------------- |
|
|
7.09.2011, 20:47:31
Post
#3
|
|
Grupa: Zarejestrowani Postów: 7 Pomógł: 0 Dołączył: 18.01.2010 Ostrzeżenie: (0%) |
|
|
|
7.09.2011, 22:18:36
Post
#4
|
|
Grupa: Zarejestrowani Postów: 664 Pomógł: 169 Dołączył: 8.01.2010 Skąd: Kraków Ostrzeżenie: (0%) |
Co do kwestii klasy user, to tworzenie jej obiektu powinno wyglądać tak:
Bez id, ponieważ jeżeli podajesz id w konstruktorze oznacza to, że użytkownik nie jest tworzony tylko pobierany z bazy. Pobieranie użytkownika z bazy powinno wyglądać tak:
I w tym momencie, jeżeli istnieje użytkownik o id 3, to klasa Users go zwraca, a jeżeli nie istenieje, to zwraca false. Dlatego też nie jest ci potrzebna metoda exists() Coś o TableAbstract:
Mniej więcej o to chodzi. Jak dobrze przemyślisz sprawę to metody update, delete i find różnią się tak naprawdę jedynie nazwą tabeli. -------------------- |
|
|
8.09.2011, 16:35:29
Post
#5
|
|
Grupa: Zarejestrowani Postów: 7 Pomógł: 0 Dołączył: 18.01.2010 Ostrzeżenie: (0%) |
w klasie user nie operuje na danych w bazie, tylko seterami/geterami pracuje na zmiennych, tak?
dopiero users::update () dłubie w bazie.
to już chyba lepiej wygląda. jeszcze chciałbym zaimplementować grupy i pola dodatkowe (np. imię, nazwisko). to też w klasie user? jeśli tak, go kiedy powinienem pobierać dane z bazy? Ten post edytował zajonc 8.09.2011, 16:36:17 |
|
|
8.09.2011, 16:55:14
Post
#6
|
|
Grupa: Zarejestrowani Postów: 664 Pomógł: 169 Dołączył: 8.01.2010 Skąd: Kraków Ostrzeżenie: (0%) |
Cytat jeśli tak, go kiedy powinienem pobierać dane z bazy? Cytat Pobieranie użytkownika z bazy powinno wyglądać tak:
A co do metody update w TableAbstract, to trochę się rozpędziłem:) To klasa User i Group powinna posiadać metodę save(), która przy nowych obiektach dodaje je do bazy, a przy tych wyciągniętych z bazy - zapisuje zmiany. Ten post edytował bastard13 8.09.2011, 16:55:46 -------------------- |
|
|
8.09.2011, 17:38:20
Post
#7
|
|
Grupa: Zarejestrowani Postów: 7 Pomógł: 0 Dołączył: 18.01.2010 Ostrzeżenie: (0%) |
users::find($uid) zwraca użytkownika ze wszystkimi wypełnionymi polami?
tj. id, name, pass, groups, custom_fields. czy też już user::get_groups dba o aktualne dane?
|
|
|
Wersja Lo-Fi | Aktualny czas: 29.05.2024 - 07:45 |