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ć.

Użytkownicy, jak sam zauważyłeś są takim samym rodzajem danych co wpis na blogu czy obraz w galerii. Ot, pytasz po prostu o ORM-a, a tu sprawa w kwestii podejścia jest właściwie jasna: Active Record bądź Data Mapper - z ogromną przewagą dla tego ostatniego.

@Crozin z tego co rozumiem potwierdzasz to co napisałem, ale nie rozwiązuje to jakoś moich pytań, może po prostu za głupi jestem i nie potrafię sobie tego przetłumaczyć. Już od kilku dni siedzę nad tym jak to ładnie wszystko wyszykować i po wielu początkach od zera najkorzystniej wygląda coś w rodzaju:

class user() - instancja użytkownika, ma zmienne (login, pass, email), metody do ich zmiany takie jak setNick($nick), usuwanie usera del() (korzysta z pliku modelu do usunięcia z bazy) i chyba tyle.
class users() - reprezentuje tak jak by zbiór użytkowników ma metody typu addUser(user ...), sprawdzanie czy dany nick jest wolny(?), wyszukiwanie w bazie użytkownika i pobieranie go (return new user())

I w takim wyglądzie mam mieszane myśli do:
- logowanie - nie wiem jak je opatentować wogóle, przydała by się kolejna klasa czyż nie?
- rejestracja - jest poprzez addUser(user ...)
- 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...

Pracuję w zend to wszystko dał bym jako biblioteki i korzystał z nich w akcjach. Wiem że strasznie mieszam z user i users, ale nie wiem jak to ładniej opisać.

EDIT:
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()?

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

Edit2:
Pogrubione przemyślenia. :-)

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.

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 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ć).
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.

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.
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.

@Crozin od pół roku uczę się zend'a i nie zmienię tego typu, zmigruję tylko na v2 jak tylko się pojawi jakaś stabilna, długo myślałem nad fw i za daleko już doszedłem by coś zmieniać szczególnie że moja aplikacja jest już dość rozwinięta i jedyne co mi zostało to przepisać od nowa takie bajki jak owy user, news itd. na chwile obecną całość jest w kontrolerach poupychana bez żadnej warstwy pomiędzy co jest imo złe i daje mi mocno po głowie.

Zaznaczasz że nie korzystam z gotowych rozwiązań, korzystam tylko nie koniecznie wiem jak je połączyć z taką klasą jak omawiana user(), takie ficzery jak Zend_Auth, Zend_Form i powiązane wykorzystuje z chęcią. I ogólnie widzę to tak że form nie ma nic wspólnego z żadną z klas o których tutaj mówimy. Krótki przykład - mam moduł user, w nim kontroler user i akcję addUser, tak pobieram forma przekazuję go do widoku po wysłaniu forma akcja zmienia się na addUserProcessing i tutaj dokonywana jest walidacja przy użyciu Zend_Form a już pewnymi danymi uzupełniam moją klasę user(), nie wiem czy poprawnie ale właśnie tak to widzę. :-) Więc pomijam takie aspekty jak właśnie walidacja danych bo to robi sam fw.

Myślał bym idąc Twoim tokiem myślenia by zrobić coś takiego, wszystko to osobne klasy:
- logowanie - tutaj wszystko co zend daje w kontrolerze jednym bez mojej ramki na to
- user - reprezentuje usera
- My_Model_Users - klasa do której przekazuje instancje user w celu dodania / usunięcia użytkownika.

Z tego wynika że biblioteką której nie mam to user i metody w module, a reszty dostarczy mi fw.

I teraz przydało by się coś do rejestracji, wnioskuję że proponujesz mi kolejną klasę która zajmie się tą czynnością, a nie lepiej stworzyć po prostu pusty obiekt user i dodać do bazy za pomocą My_Model_Users -> add(user ...)?

Ważnym pytanie jest jak mają być aktualizowane dane rozumiem że wprowadzam zmiany w user i w My_Model_Users -> up(user ...)?

Dzięki wielkie za tracenie na mnie czasu, po prostu czytam czytam i próbuję odnaleźć dla siebie jakaś drogę by to pojąć połączyć z narzędziami zend'a i by to nie tyle działało co było poprawne w sztuce programowania, bo napisać byle jak to każdy umie. :-)

1. Zenda możesz bez problemu połączyć chociażby z Doctrine: http://stackoverflow.com/questions/5001488...e-2-integration
2. Możesz całość wykorzystać z Zend_Auth: https://www.google.com/search?q=zend+auth+d...600&bih=775

Cały czas pytasz o ogólną architekturę aplikacji, więc pokrótce:
1. Reprezentacja danych, tj. obiekt User odpowiedzialny za reprezentację pojedynczego użytkownika.
2. Pobieranie danych.
2.1. Typowe podejście, tj. obiekt UserRepository zawierający metody typu find[One]BySth(...)
2.2. Obiekt pozwalający na dynamiczne budowanie kryteriów.
3. Wykonywanie operacji na tych obiektach, czyli warstwa serwisowa. https://www.google.com/search?q=domain+serv...me&ie=UTF-8
4. Zapisywanie/usuwanie obiektów ze źródła danych ,czyli DAO, który w swoim wnętrzu wykonuje operacje utrwalania/usuwania danych przy pomocy ORM-a.

Ja tylko wtrące w temacie. Po co mu Crozin tak usilnie wciskasz Doctrine (przeładowaną krowę z bezsensownymi adnotacjami na siłę przeniesionymi z Javy) jak wyraźnie napisał że korzysta z ZF który pięknie integruje się, co oczywiste, z Zend_Db?

Byl juz podobny temat.
Temat: prawidlowe OOP struktura klasy