class user() czyli oop i organizacja użytkowników Opcje

[ShadowD]

Jestem ciekaw jak Waszym zdaniem powinna wyglądać class "user()" reprezentująca użytkownika, jak stworzyć "fabrykę" takich użytkowników i jak ogólnie ogarnąć ten temat.

Z ogólnych zasad można by wywnioskować coś mniej więcej takiego:

[PHP] pobierz, plaintext 
<?php
 
class User
{
    private $_nick;
    private $_pass;
    private $_email;
 
    public function getNick() {}
    public function setNick() {}
 
    public function getPass() {}
    public function setPass() {}
 
    public function getEmail() {}
    public function setEmail() {}
 
    public function delate() {}
}
 
?>
[PHP] pobierz, plaintext 

To jest moja wizja i może być mocno błędna, ale zakładam że Instancja tej klasy będzie reprezentował jednego użytkownika.

I teraz jeśli w bazie mamy dane o użytkownikach i chcieli byśmy stworzyć taką instancję to w jaki sposób się do tego zabrać?

Ja tutaj widzę jakąś klasę users() (nie wiem jak ją nazwać - "fabryką"?), która miała by metody do wyszukiwania użytkowników i coś w rodzaju getUser(), ale czy taka wizja jest poprawna czy może jesteście w sanie naprostować mój światopogląd lub dać jakiś przykład jak to powinno wyglądać? Jak w takim przypadku tworzyć nowego użytkownika np. podczas rejestracji (czyli $user = new user() i teraz co? $uses->addUser($user)) a potem go zapisać?

Przykład na użytkownikach, ale sprawa jest identyczna do wpisów czy stron na blogach, chciał bym mieć jeden wypracowany szablon, a przy natłoku różnych sposobów z sieci sam już nie wiem jak to prawidłowo zapisać.

[Crozin]

Pierwszy błąd: nie korzystasz z gotowych rozwiązań. Potrzebujesz ORM-a, więc na początek powinieneś skierować się w stronę Doctrine2. Potrzebujesz rejestracji/logowania, więc powinieneś skierować się w stronę Symfony/Zend/inny FW.

To o co pytasz i co opisujesz to ORM oparty o architekturę Active Record. Możesz podejrzeć sobie ORM Propel czy Doctrine w wersji 1.2.

- logowanie - nie wiem jak je opatentować wogóle, przydała by się kolejna klasa czyż nie?

Raczej ciężko by użytkownik w sensie typ danych taki sam jak wspomniany wpis na blogu czy komentarz pod wpisem był używany jako mechanizm autoryzacji. Może on być co najwyżej jego częścią.

- rejestracja - jest poprzez addUser(user ...)

Rejestracja podobnie jak logowanie to proces dosyć złożony - w końcu w jej skład wchodzi odebranie i przetworzenie danych od użytkownika (np. z formularza na stronie, bądź z "sieci" OpenID), utworzenie i zapisanie w jakiejś bazie danych mniej lub bardziej złożonej struktury reprezentującej użytkownika itp.
Ponownie, jeżeli skorzystał byś z gotowego rozwiązania, np. Symfony/Zend, nie musiałbyś zajmować się takimi pierdołami (szczególnie, że nie wiesz nawet jak się za nie zabrać).

- może usuwanie użytkownika powinno być w klasie users() jako metoda del(user ...) przyjmująca instancję user? - To trochę bez sensu bo mając tylko id muszę najpierw tworzyć instancję user co jest równoznaczne z pobieraniem całego kompletu informacji na jego temat taka nadmiarowa praca...

Pobieranie użytkownika tylko po to by go usunąć rzeczywiście na pierwszy rzut oka nie ma sensu, ale:
1. Z reguły i tak będziesz potrzebować ten obiekt, bo przed usunięciem trzeba wykonać jakieś operacje na nim.
2. Nie wpłynie to negatywnie na aplikację.
3. Porządny, rozbudowany ORM będzie na tyle inteligentny, że nie koniecznie będzie pobierał jakiekolwiek dane z bazy w tym przypadku - chociaż nie wiem czy w PHP jest jakieś projekt obsługujący już taki "ficzer".
4. Będzie to najbardziej "poprawne", a przez to wygodne w użyciu rozwiązanie z punktu widzenia OOP - w końcu to paradygmat zakładający pracę na obiektach, a nie jakiś tam detali ich implementacji.

Kolejnym pytaniem jest czy metody typu setNick moją od razu zapisywać dane w mysql, czy też poprzez $users->saveChange(user ...), a może po prostu poprzez $user->save()?

Natychmiastowe zapisywane danych byłoby bardzo złym pomysłem. Przy aktualizacji trzech właściwości czterech obiektów miałbyś 12 transakcji w bazie danych. A to z punktu widzenia wydajności i co ważniejsze spójności danych fatalne rozwiązanie.

I czy przy takich założeniach klasa users powinna być modelem - takim typowym modelem z mvc? (W zand w katalogu models)

Model to najszersza z warstw w niemal każdej aplikacji webowej, i tak, ta klasa będzie jego częścią; A co to jest "Typowy model z MVC z Zenda" nawet nie wiem. Warstwa modelu ma tyle kompletnie różnych typów obiektów, że nie potrafię sobie wyobrazić, która jest "typowa".

Podsumowując: skorzystaj z gotowego rozwiązania do tak podstawowych rzeczy. Mój typ: Symfony2+Doctrine2 - bo korzystają z nowych elementów PHP wprowadzających odrobinę cywilizacji, a ich architektura jak i spora część kodu jest zerżnięta z najlepszych fragmentów innych projektów. A to niezwykle dobra cecha.

Ten post edytował Crozin 24.08.2012, 01:09:28