Discussion :

[tigunn]

Bonjour a tou(te)s!
je vais faire mon premier projet en php objet. Comme je manque encore de méthodes je voulais savoir si vous pouviez me conseiller sur les objets qu'ils seraient bon de définir pour gérer l'authentification de nos utilisateurs.
Par exemple, si on considère que j'aurais des utilisateurs (plusieurs utilisateurs par entreprise cliente), des groupes, des droits d'accès différents selon les groupes (relation n à n).
Dans cet exemple, je distingue facilement 4 objets: Client, Utilisateur, Groupe, Droit. Mais que faire pour les tables de liaisons comme Droit_par_Groupe?
Et est-ce que mon raisonnement est bon ?

[jnore]

Avant de commencer en php, visiblement, il te faut construire ta base de données.
Sur celle-ci tu devra créer des liens entre les utilisateurs et les différents groupes. Tu devrais faire un shéma à la main pour commencer. Ca parait bête mais c'est efficace.

[tigunn]

j'ai déjà fait cette partie là de l'analyse. Modèles et bases de données prêtes.
Après ce que je voudrais savoir c'est quels objets sont à définir? est-ce que l'on peut (il faut que cela vaille le coup) développer une application totalement objet avec php?
Y a surement des pieges bateau que l'on peut eviter avec une technique et un peu d'experience...
Enfin, sinon Jnore, je continue mes dessins... tant que je pense que l'analyse n'est pas completement finie.

[Seth77]

Slu

tu px partir sur un modele MVC ... ou tu auras une classe qui s'occupe de communiquer avec la BDD et des classes herites qui correspondent aux objets de ta BDD ...

l'avantage avec une classe qui s'occupe de la bdd est que si tu change de type de bdd tu n'auras a modifier que cette classe ... et les autres ne bougerons pas, vu que tu n'utilisera que des requetes SQL

@+

[Yoteco]

En effet si tu fais un site entièrement OBJET je te conseille d'utiliser le design pattern MVC. Sinon pour ton projet moi je ferais un objet user qui à des propriété qui définisse sont statut (utilisateur ou client) puis une propriété qui définie son niveau d'accès et une propriété pour l'id du groupe et puis tu stocke sa dans une session (que je protégerais) et puis tu peux faire tes teste en utilisant les classe 'M' (model) pour communiquer avec la base de données.

[defus]

N'oublie pas aussi d'utiliser des composants existants.

Je prend l'exemple de PEAR\Auth qui gère l'athentification avec possibilité de l'intégrer dans divers scénarios d'architecture (BD, LDAP, FTP, ...)

C'est essentiel d'avoir en tête la facon dont ces composants fonctionnent pour ne pas te planter dans ta conception initiale.

A mon sens, évite les longues modélisations à la Mérise, mais construit plutot rapidement un premier prototype de ton application. En voyant fonctioànner ton prototype, tu pouras par la suite refactorer et mieux concevoir ton appli (Extrem programming et autre méthodes RAD)

[tigunn]

Merci de vos réponses.

Je vais me renseigner du côté des modèles MVC et

l'exemple de PEAR\Auth qui gère l'athentification

ça aussi, parce que je ne vois pas ce que c'est.
Pour la connexion à la base je pensais utiliser PDO. C'est bien?

Lundi matin :
Voilà un peu comment je comptais procéder:

Ca ressemble à une structure MVC, mais je pense que ce sera moins propre .

[defus]

Auth t'offre les fonctions de création des mots de passes cryptés pour tes utilisateurs et surtout gère l'authentification des utilisaters à ton application. La seule contrainte qu'il t'impose c'est d'avoir une structure de persistance (une table dans ta bd par exemple) et de lui spécifier le moyen que tu utilise pour te connecter à ta bd. Par exemple, si les info de tes users sont stockés dans une bd, il peux utiliser le package d'abstration DB pour se connecter à tout type de BD.

Pour ce qui est de PDO, c'est bien. Et pour faire plus éfficace, je te conseille de regarder le projet Propel. C'est un mapper object relationnel. C'est à dire qu'il peut te générer toutes les classes d'accès à la base de donnée et de manipulation des données une fois que ta structure de donnée est prète. La version 2.3 de Propel utilise en arrière plan PDO pour gérer les accès BD (he oui!). Si tu n'a aucune idée sur les mappeurs, le plus célèbre d'entre tous les surement Hibernate (java). Ce sont des mécanismes qui t'évitent d'écrire une nième fois les fonctions simples (create, read, update, insert)

[tigunn]

ça semble intéressant mais j'ai bcp trop de problèmes à installer PEAR, Phing et Creole avant de pouvoir installer Propel.
je cherche tuto simple pour mettre en place Propel

Si il fait réellement la génération de tes classes et fonctions d'accès aux données.

[tigunn]

Enfin bon. Ce qui me pose problème c'est de savoir quels objets doivent être créés.
Je pense faire les objets :Utilisateur, Client (société), c'est le minimum. De manière que je puisse les conserver d'une page à l'autre en linéarisant l'objet et en le stockant dans $_SESSION.
Ce que je souhaitait faire c'est gérer mes "campagnes (publicitaires)", leurs différentes "diffusions", les mailings du client, ... etc mais je voudrais savoir comment , ou quand, les créer.??

Si j'essaye de recapituler:
-un user lambda accède au site et tombe sur la page d'authantification
-lambda se log correctement
-> donc je crée deux objets Utilisateur et Client avec les infos que je recupere dans la base.
-lambda est authentifié sur le site, sa session est créée
Mais quel est le mieux à faire ensuite pour avoir mes campagnes, diffusions, ...
>> je crée les objets tous au même moment?
>> je crée les objets au chargement de la page pour laquelle j'en ai besoin (exemple 1 Client a n campagnes, et, 1Client a n fournisseur; mais les fournisseurs et les campagnes pour ce client n'apparaissent pas sur la même page)?
>> autres?