Méthode statique ou que des objets ?

Bonjour,

je m'interroge sur ce choix de conception : dans une architecture MVC, les classes du modèle peuvent-elles comporter des méthodes statiques ?
En clair, je souhaite créer une méthode qui interrogerait la bdd pour obtenir la liste des utilisateurs. Donc du genre public function getUser():array, le tableau retourné étant la liste des utilisateurs. Cette méthode appartient à la classe User. A priori, c'est une méthode générique, donc pas liée à un utilisateur particulier, donc il me semble logique qu'elle soit statique. Quel est votre avis ?

Rien ne l'interdit.

Maintenant si ton modèle est une représentation stricte d'un utilisateur ce n'est pas forcément le bon endroit pour mettre cette fonction.
Si au contraire ton modèle est une classe une peu générique et qui touche tout ce qui concerne le ou les utilisateurs alors pourquoi pas.

À mon avis, ça n'a rien à faire dans ta classe User pour une raison simple: ta classe User réunit les attributs et méthodes nécessaires à la manipulation d'un utilisateur pas d'un ensemble d'utilisateurs.
À ta place je créerais une classe UserCollection avec des méthodes utiles pour gérer un ensemble d'instances de User dont une méthode non-statique qui te renvoie sous une forme ou une autre l'ensemble des utilisateurs d'une instance. Une instance d'une telle classe peut regrouper un, deux, vingt ou tous les utilisateurs de ta base ça n'a aucune importance.

Merci pour les réponses, et ça tombe bien car j'avais fini par faire la même réflexion ; j'avais créé une deuxième classe (que j'ai renommée car la proposition de Cosmo est mieux) : TicketModelCollection et cette classe comporte des méthodes non statiques...

Bonjour,

L'approche utilisant les méthodes statiques est une implémentation assez courante du pattern ActiveRecord :

Code:

---

1 2 3 4

$users = User::findAll(); //liste $user = User::findOne( $id ); //un utilisateur $user->save(); $user->delete()

---

C'est très pratique; le code est simple et lisible, et cela permet de regrouper toutes les méthodes de manipulation du modèle dans une classe et évite d'avoir à créer deux classes pour chaque modèle.

C'est par exemple l’approche suivie par le framework Yii.

Je suis parti sur cette approche dans mon framework/CMS. Tous mes modèles étendent une classe de base ActiveRecord, qui contient les méthodes statiques permettant de récupérer les objets.

Mais effectivement, l'utilisation de méthodes statiques pour récupérer des objets est très controversée.

D'une manière générale le pattern ActiveRecord est très décrié. Certains considèrent qu'il va à l’encontre des bonnes pratiques de POO et qu'il s'agit d'une violation du principe de responsabilité unique. L'utilisation de méthodes statiques peut également poser problème pour l'injection de dépendances.

Tout dépend de tes objectifs. Généralement on considère que c'est adapté à des applications assez simples.

Si tu décides de séparer les fonctionnalités avec 2 classes, je te conseillerais d'avoir une classe Finder qui contient les méthodes pour récupérer les utilisateurs, plutôt qu'une classe UserCollection :

Code:

---

1 2 3 4 5

$userFinder = new UserFinder(); $users = $userFinder->findAll(); //liste $user = $userFinder->findOne( $id ); $user->save(); $user->delete()

---

Mais quitte à créer deux classes, tu pourrais passer à une approche de type DataMapper :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

//Entité User : gère toute la logique métier de l'utilisateur, mais pas la persistence. class User { //... }   //UserMapper : gère la récupération des objets ou la sauvegarde en base de données : class UserMapper { public function findOne() { //... } public function save(User $user) { //... }   $userMapper = new userMapper(); $users = $userMapper->findAll(); //liste $user = $userMapper->findOne( $id ); //un utilisateur   $userMapper->save( $user ); $userMapper->delete( $user )

---

Bonjour,
mon approche est différente de celles que tu proposes : certes, j'ai 2 classes, mais en gros le principe est le suivant :

Code:

---

1 2 3 4 5 6 7 8

class User { // gère la logique métier et l'écriture en bdd }   class UserCollection { //gère la lecture en bdd }

---