![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 71 Pomógł: 0 Dołączył: 5.03.2011 Ostrzeżenie: (0%) ![]() ![]() |
Witam
Temat pewnie wam znany i stary jak swiat. Pisze sobie swoj cms starajac sie zrobic to obiektowo. Dotychczas przejrzalem i przeczytalem wiele artykulow dotyczacych OOP i robie sie coraz glupszy bo z tego co rozumie to zastosowan jest multum, tylko ktore to najlepsze. mam taka klase
Pierwsze pytanie : Czy klasa User powinna miec funkcje takie jak Loguj, Rejestruj, Edytuj, Zmien Haslo i czy te funckje powinny miec juz "hardcoded" zapytania do bazy wewnatrz, patrz funckja loguj();. Wywoluje ja tak:
Jezeli cos tego pokroju jest ok to spoko. Teraz np dopisalem sobie taka funkcje to tej samej klasy, ktora jak dla mnie moglaby byc w kazdej prawie innej klasie :
Dzieki tej funkcji lapie sobie wszystko z bazy i w prosty sposob moge wywolywac wszystkie kolumny :
Bardzo podoba mi sie mozliwosc poboru rekordow i nazw wierszy tabeli w tak prosty sposob. Teraz do rzeczy : Funckja ta jest w Users ale generalnie moglaby byc w prawie kazdej innej klasie, np Products, Articles itp. Czy mam utworzyc osobna klase z ta funckja z ktorej jakos beda kozystac wszyskie inne klasy ? Czy ma byc to w klasie bazy danych, czy moze w jakies jeszcze innej ? Prosze o odpowiedzi i wyrozumialosc (IMG:style_emoticons/default/smile.gif) Ten post edytował rahul 20.08.2011, 20:50:56 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 226 Pomógł: 61 Dołączył: 20.08.2010 Ostrzeżenie: (0%) ![]() ![]() |
@by_ikar Dyskusja o getterach i setterach wyszła od klasy User, której właściwości nie zmieniają co wywołanie strony, więc skąd te argumenty o sprawdzaniu wartości w tablicy POST? Nawet to, co napisałeś na poprzedniej stronie, czyli dodawanie niestandardowych pól do profilu użytkownika, nie wymusza korzystania z pojedynczych funkcji get() i set() w klasie User:
Później podczas aktualizacji danych użytkownika UserManager porówna klucze tej kolekcji z możliwymi kluczami dodatkowych pól użytkownika. Rozpoznane wartości powędrują do bazy, nierozpoznane zostaną zignorowane (plus dodany zostanie wpis do logów) @rahul Funkcje login(), logout(), register() mają być "jeden poziom wyżej" niż UserManager (nie podałeś co jest u ciebie tym poziomem). Np. jeśli korzystasz ze wzorca MVC, to funkcje te będziesz miał w modelu. Zostaną wywołane z kontrolera, zrobią to co mają zrobić (walidacja, operacje na bazie przy użyciu UserManagera, zapisanie informacji w sesji) i zwrócą rezultat kontrolerowi, który zdecyduje co dalej zrobić (np. przekierowanie na inną stronę) |
|
|
![]() ![]() |
![]() |
Aktualny czas: 3.10.2025 - 05:48 |