2011-01-07 3 views
2

Je construis une classe d'utilisateurs qui gère la création, la suppression et la modification d'un utilisateur générique. Ma classe doit être utilisée de cette façon:Une classe d'utilisateurs, bonne approche?

# creation 
user::create($username, $password, $email); // Does not need of $id 

# modification 
$u = new user($id); 
$u->edit('password', $new_password); 

# deletion 
$u->delete(); 

Fondamentalement, la classe contiennent une méthode statique create() qui ne nécessite pas l'obliviously id utilisé comme argument. Après la création, vous pouvez rassembler des informations utilisateur et gérer l'utilisateur en créant une instance de l'utilisateur de la classe et définir en argument le $ id de l'utilisateur. Est-ce une bonne conception ou devrais-je créer quelque chose comme:

# creation 
$users = new genericUserMethod(); 
$users->create($username, $password, $email); 

# modification 
$u = new specificUser($id); 
$u->edit('password', $new_password); 

# deletion 
$u->delete(); 

... Créer 2 classes différentes. Ou y a-t-il un autre moyen?

Répondre

3

Cela pourrait être une approche:

class User { 
    private $id; 
    private $name; 
    //more fields here 

    public function __construct($id = null) { 
     $this->id = $id; 
     if(!is_null($this->id)) { 
      $this->load_user_data(); 
     } 
    } 

    protected function load_user_data() { 
     //select from DB where id = $this->id and populate fields 
    } 

    public function save() { 
     //if $this->id is null insert the user details in DB and populate $this->id with new user's id 
     //else update DB with field (optionally check what has changed and update only if necessary) 
    } 

    public function delete() { 
     //delete user if $this->id is not null 
    } 

    //fields getters and setters here as needed 

} 

Exemple d'utilisation:

$mary = new User(); //fresh new user 
echo $mary->getId(); //returns null as this user is not inserted. 
$mary->setName('mary'); 
$mary->save(); //insert user with name mary in the DB 
echo $mary->getId(); // returns an id as this user is now inserted 

$john = new User(2); // we assume there was a user john in DB with id = 2 
echo $john->getName(); //echoes 'john' if this was his name in DB 

Vous pouvez même définir des méthodes statiques dans la classe comme getActiveUsers() qui retourne un tableau avec les utilisateurs actifs par exemple ..

Note: Ceci est destiné à des besoins assez simples, dans le cas où vous avez besoin de faire dome comple x choses que je vous recommande d'utiliser une bibliothèque ORM comme indiqué @ Quelle est la question

+0

J'aime ça aussi, et c'est ce que j'ai fait dans le passé. Peut-être ajouter un peu d'utilisation (création de nouveaux utilisateurs, chargement d'anciens, suppression, etditing, etc.) ... Autre que cela, +1 – ircmaxell

+1

L'utilisation du constructeur pour charger implicitement l'objet de la base de données n'est pas un 'bon design'. Vous ne pouvez pas avoir la possibilité d'indiquer que le $ $ donné n'est pas présent dans la base de données. De plus, le constructeur ne devrait servir qu'à créer de nouvelles instances valides d'une classe. -1 – mschneider

+0

@mschneider vous avez raison, le constructeur pourrait aussi être paramétré comme protégé et faire 2 méthodes statiques "créer" et "charger" par exemple qui appelle en interne le constructeur ... mais cela était juste comme un simple skeletton ... – maid450

2

Le premier. Peut-être que vous devriez regarder ActiveRecord/ActiveModel pour quelques inspirations supplémentaires.

2

deux façons populaires de gérer cela sont Active Record et Data mapper. Doctrine 1 utilisé Modèle d'enregistrement actif et Doctrine 2 utilise Data Mapper. En bref:
- avec enregistrement actif, vous avez la classe qui gère les données et la persistance
- avec Data Mapper vous avez la classe de données et la classe qui gère la persistance

Aussi il y a motif Data Access Object qui peut aller au-dessus de l'une des mentionné ci-dessus. Votre premier exemple ressemble à un modèle d'enregistrement actif avec un raccourci statique déraisonnable pour l'objet d'enregistrement de construction (pourquoi ne pas avoir plusieurs constructeurs ou optionnel id - null pour new, integer pour existant).

Le deuxième exemple ressemble à DAO en plus de l'enregistrement actif et semble plus usuel.

Questions connexes