non oublie le dossier include qui n'a pas de sens.
ça ne veux rien dire include
moi j'utilise ça
/librairie contient comme son nom l'indique des librairie php (ZF Pear pdflib etc.) bref des librairy qui ne sont pas des élément propre à l'application mais qu'on retrouve d'appli en appli
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6/application /controllers /model /views /library /public
/application contient tout le code de l'application
avec les sous dossiers pour retrouver ses petits (et ne pas avoir un include qui contient tout)
/public est un dossier qui contient des élément accessible du navigateur (sans passer par php)
comme les css les js des fichier html etc.
A+JYT
A titre perso, je mettrais pas d'ouverture d'une connexion à la base de données dans le constructeur. Il faudrait que tu puisses avoir la maitrise de l'endroit ou tu veux l'ouvrir.
En gros,
En gros, il faut pouvoir avoir la possibilité de gérer l'ouverture et la fermeture de la base de données et non au bon vouloir de la présence ou non de la classe.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33 <?php class bdd { private $linkDb; public __construct() { $this->LinkDB = null; } public function __destruct(){ $this->Close(); } public query($sql) { return mysqli_fetch_assoc(mysql_query($sql)); } public function Open(($host,$login,$pass,$bdd) { $this->LinkDb = mysqli_connect($host,$login,$pass,$bdd); } public function Close(){ if($this->isOpen()){ mysqli_close($this->LinkDb); $this->LinkDB = null; } } public function isOpen(){ return (is_null($this->LinkDB))?true:false; } } ?>
Dans mon cas personnel je l'utilise avant tout autre appelle de classe ayant besoin d'une connexion et je le diffuse.
En gros
Mais en faite la clase maClasse hérite d'une classe qui s'occupe de gérer la diffusion. En gros, la méthode setDb n'est pas présent physiquement dans maClasse mais dans la classe générique.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 $db = new db(); $m = new maClasse($db); ou $m = new maClasse(); $m->setDb($db);
Toute classe héritant de Maman pourront être arrosé par l'objet DB.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20 class Maman{ public $objDb; function __construct(){ $this->objDb = null; } public function setObjDb(DB $p_db){ $this->objDb = $p_db; } public function getObjDb(){ return $this->objDb; } } class Fille extend Maman{ ... }
En faite, cette technique me permet d'utiliser différente SGBD sans que cela affecte les classes. Cela marche que si tout est bien organisé
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 interface IFrontController { public function executerAction(); } class ClassFrontController implements IFrontController { private $_returnRequest; public function __construct($request){ return $this->_returnRequest = $request; } public function executerAction(){ $fileName = $this->_returnRequest['action'] ; define("FILENAME_MODEL" , "./models/Model{$fileName}.php"); define("FILENAME_VIEW" , "./views/View{$fileName}.php"); file_exists(FILENAME_MODEL)?require_once(FILENAME_MODEL):error_log(FILENAME_MODEL .'model does not exists', 3, "/logs/ctrl.log"); file_exists(FILENAME_VIEW)?require_once(FILENAME_VIEW):error_log(FILENAME_VIEW .'view does not exists', 3, "/logs/ctrl.log"); } }
au moment ou tu crées une classe fille, tu écris juste :
?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 $mydb=new db(); $myfille=new Fille(); $myfille->setObjDb($mydb); //là la fille a un objet db et peut l'utiliser ?
je trouve que c'est un peu pareil que d'avoir un global $db... non ?
je comprends pas ce que tu fais...
c'est l'équivalent de mon index.php ?
ca sert à quoi ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 $fileName = $this->_returnRequest['action'] ;
Le problème des globals c'est qu'on casse un peu les objectifs de l'objet et de l'encapsulation, enfin ceci reste que mon point de vue.
Alors ma réponse reste personnel et c'est ce que j'utilise en ce moment dans mon projet.
1er rempart : Les données du formulaire passe dans une classe contrôleur qui lui gère les données
2eme rempart : s'occupe de placer les informations dans la ou les classes adéquates.
3eme rempart : Le contrôleur va ensuite appeler la classe qui s'occupe de faire le lien entre la base de données et cette objet.
Dans ton exemple cette classe sera "DataUtilsateur". Seul cette classe à le droit de communiquer directement avec la base de donnée et dans ça limite autorisé. Elle possède toute les requête SQL concernant la gestion de l'utilisateur. Elle possède tout les contrôles nécessaire avant de mettre n'importe quoi dans la base de données. C'est le 3eme rempart de sécurité de la bonne conformité de données. Le 4eme rempart se trouve dans la base de données parce que dans mon cas, il y a aucune requête SQL de type SELECT, INSERT, DELETE ou UPDATE dans le PHP. Seul l'appelle d'une procédure stocké est accepté. La raison est que je déplace une bonne partie de la logique métier à la base de données.
L'avantage c'est qu'il y a quasiment pas de code PHP pour gérer les données quand elles ont une interaction entre elle.
En résumé.
Cette technique présente l'avantage que je sais que ma donnée va toujours passer par un endroit précis, par le même chemin. L'inconvénient c'est que c'est un peut plus long à coder mais quand la structure est en place c'est aussi fluide que de l'ether
Je rajouterais ma pierre concernant une bonne habitude à prendre en développement.
Écrire du code c'est comme écrire un livre. Si vous demandez à plusieurs personnes d'écrire un livre sur le système solaire, vous aurez autant de façon d'expliquer le système solaire. Pourtant, le système Solaire est telle qu'il est 9 planètes etc.
Pour le développement c'est un prêt la même chose. On vous donne un cahier des charges et vous devez finaliser le projet à la manière du développeur.
Je dis "à la manière du développeur". En effet, même si, il y a des protocoles bien strict vous ne pouvez pas transformer ou vous transformer en robot et faire du code des manières strict et en 100% en accord avec le protocole.
Ceci est encore plus vraie quand vous êtes seul. Plus facile quand vous êtes plusieurs voir préférable.
Ce que je veux dire, c'est qu'au début d'un projet; pour un client, ou pour vous. Il est préférable de penser à un protocole d'écriture et d'organisation du projet.
Pour être précis, c'est qu'il faut garder la même manière de coder du début à la fin. Pourquoi ? Si vous passez la main à quelqu'un d'autre, celui-ci peut être dérouté par votre manière. Mais avec le temps, il va finir par comprendre comment vous fonctionné. Le plus important pour lui c'est qu'il ne faut pas changer en court de route.
Bien évidemment, ceci marche seulement pour les personnes ayant un minimum d'expérience dans le langage. Il ne faut pas que être brouillon.
Par contre, dans une équipe il est important d'avoir un protocole commun mais ne pas chercher à figer le protocole car il est important de respecter une manière, un style à chacun. C'est petite marge permet d'augmenter la créativité de chacun. C'est dans de ces moment là qu'il y a des idées qui naissent. Parfois des bugs aussi .
Il y a des cas extrême à laquelle il faut éviter de rentrer et réfléchir là ou il faut. Je vais prendre l'exemple du typage en PHP.
Certaine personne code ainsi.
Cool vous avez indiqué le type mais à titre personnel cela ne sert pas à grand chose.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 $intNbUser = 0; $strName = 'Frippouille'; $boolIsConnected = true;
Même exemple, seul les singes ne verront pas que Nbxxx n'est pas forcément un nombre et $Name n'est pas forcément une chaine de caractère. Ce que je veux dire par là, c'est que je cherche pas à insulté les personnes faisant cela. Mais, qu'il faut pas se surcharger de protocoles inutile pensant que cela fait partie d'une bonne organisation.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 $nbUser = 0; $Name = 'Frippouille'; $isConnected = true;
Dans notre cas, Le plus important c'est qu'elle est le rôle de cette variable. Un nom explicite est largement suffisant que de rajouter le type. De plus, si le code est assez bien organisé, c'est à dire avec une phase d'initialisation des variables, vous en aurez encore moins besoin car vous verrez de suite son rôle.
Cette histoire de variables n'est qu'un exemple mais l'idée principale d'éviter de perdre son temps sur ce genre de point de détails et s'axer sur la logique de l'ensemble du code, parce que si le code n'est pas logique ;indication du type ne sert à rien.
A titre personnel, j'applique le type de variable seulement pour des cas précis.
$objMonObjet, $collMaCollectionObjets,$arrMonTableau.
J'en parle par expérience parce que je suis tombé sur des personnes ainsi. Ils perdaient plus leur temps à définir un protocole dans ce genre là.
Que :
- Les accolades se mettent à la ligne;
- Les variables doit avoir le type dans le nom;
- Les noms des objet doit commencer par Obj (Ridicule )
Mais au final leurs codes étaient mal organisé et codé l'arrache ce qui fait que c'était truffé d'erreurs. Par contre le protocole était .
Mais bon, si vous le faite quand même (histoire des types dans la nom de la variable) c'est pas plus mal., surtout si le code est claire, organisé, logique et compréhensible. Je dis pas qu'il ne faut pas le faire -hein
C'est toi
En faite je parlais de :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 <?php class objMonObjet{ } ?>
Là, je ne suis pas d'accord.
En toute logique, il faut utiliser l'abstraction, et malheureusement, ca se traduit par du code en plus. C'est nécessaire pour découpler les éléments d'une application.
Pour reprendre l'exemple de la liste d'utilisateur, sur la couche modele.
Voilà comment j'organiserais ca. (Au passage, je modifie mon propos de mon post precedent).
J'utilise 4 classes.
UserService : Classe visible par le controleur.
Cette classe delivre une liste d'utilisateur (au sens metier du terme)
User : Cette classe represente un utilisateur.
UserProvider : Cette classe fourni des methodes pour sauvegarder en base ou charger des user.
SgbdProvider : Classe d'accès à la base de données (et eventuellement, via PDO).
Pourquoi avoir séparé User et UserProvider ?
User est bien l'utilisateur en lui meme.
Trouvez vous normal qu'on y place des appel à une base de données ?
Pensez vous que l'objet user doit savoir ou se trouve les données d'un User ?
Doit il savoir si l'abjet est en base, en annuaire, dans un fichier ?
Non, et ce n'est pas son role.
La seule chose que doit avoir l'objet user, c'est une méthode qui lui permet de loader un user, ou le sauvegarder. (load() et save(), par exemple ^^ )
load() et save() devraient invoquer une methode d'UserProvider.
C'est Userprovider qui doit décider de quelle source nous avons besoin.
Elle doit par exemple generer la requete SQL, et la faire executer via sgbdProvider.
Chacun son role.
Un provideur, il est là pour alimenter, fournir.
Toute la problématique est donc de savoir ou placer son code.
Telle traitement doit se faire au même endroit.
Lorsque c'est respecté, je vous assure que c'est 100 fois plus rapide à maintenir. Meme si il y a un peu plus de classe, on sait directement ou intervenir.
Et pour reprendre mon quote du début : en maintenance, la situation la pire est de faire du reverse sur du code. Tu perds plus de temps à essayer de comprendre la logique du développeur, que le code en lui même.
Et c'est d'autant plus important de découpler les briques, que les applications sont souvent maintenues pas des personnes differentes au cours du temps...
Autant garder une logique eprouvée, et un couplage lache (principe roi en SOA) pour assurer les evolutions le plus en douceur possible.
Ah oui ... utiliser les globals, c'est le meilleur moyen de s'appercevoir qu'on a pas saisie l'interet du multicouches et de l'objet (je ne me moque pas, on est tous passé par là).
Avec tout ces gens qui disent tous (qui nous "assure" tous !) que leur solution est la meilleure, on s'y perds un peu.
Cela me rappelle une blague (excusez ma digression ^^) :
- Combien faut il d'ingenieur C pour changer une ampoule ?
- Un seul... mais il en faut 30 un mois après pour comprendre comment il a fait.
Nous avons tous une manière de coder différente, d'organiser nos classes, de fournir ou non des interfaces a nos objets, etc... Comme il l'a été dit, l'important n'est pas de trouver "la meilleure solution", elle n'existe pas... sinon ca ferait longtemps que le code serait généré par un programme entierement automatique ;o)
L'important c'est de :
* Etablir des regles en s'inspirant d'un ou de modeles existants (MVC ou autre)
* Coder en respectant ces regles
Si en plus le ou les developpeur ont une pincée de bon sens (ce qui manque plus que tout en informatique...) alors ca ne pourra pas être completement mauvais.
Permes moi de répondre à ta réplique
Initialement, en lisant ce topic sur la meilleur façon de coder en PHP, nous en sommes venu à parler de MVC. Tu peux coder sans MVC, mais non seulement, tu risques de t'embourber, mais en plus tu ne te vendras jamais auprès d'une boite qui cherche un développeur
J'ai vu que certains ici pensent que pour coder en MVC, donc en couche, il était important, voir capital, d'utiliser un framework.
A ça, je réponds NON. C'est inutile lorsque on est trop léger en MVC.
Ca me parait logique. Pour bien utiliser un outil, il faut savoir pourquoi il a été fait, et surtout, en quoi il va nous simplifier la vie.
Si tu commences à te pencher sur le MVC, et qu'en plus de ça, tu dois apprendre les subtilités d'un framework, tu vas vite finir par laisser tomber. C'est un gros boulot ... Pour le peu que tu changes souvent de techno, tu risque d'être rebuté très (trop) vite.
J'essayais juste de faire comprendre que framework et MVC, ce sont deux choses différentes, et que tu peux maitriser la programmation en couche sans utiliser un seul framework. C'est non seulement très utile, mais c'est surtout très formateur.
On a souvent des cas de figure très différents. certains vont préférer coder style RAD. D'autres vont vouloir être plus posés, plus lent, plus réfléchis...
C'est à chacun de voir ... Mais, pour avoir vu quelques lignes de code tourner, et les problématiques du développement pourri, j'ai choisi mon camp
Que ce soit en Php, java, C#, ce genre de conseil est utile.
Il y a du bon à prendre dans chaque monde.
Ex : Java et son fonctionnement objet robuste
Ex : La simplicité apparente de PHP
Sinon, ce n'est pas demain la veille que les machines vont générer le code à notre place. reprenons mon exemple:
En fonction des besoins (évolutions possibles, monté en charge, temps de réponse, etc), plusieurs façon de procéder sont possibles. C'est l'art de placer le métier ...
Certains vont faire des classes en PHP, d'autres vont faire des traitement en procédures stockées ... Il n'y a pas de recette miracle, et à chaque solution ses avantages et contraintes.
Il y a juste quelques notions qu'on reverra souvent, quelque soit le cas de figure.
Et pour moi, un découpage logicielle logique est ultra important.
Il te permet de réutiliser ton code, avec le moins d'effort possible.
Donc, à moindre cout, car plus rapidement.
Et le temps, c'est de l'argent (comme le disent tous les patrons .
Après, chacun fait comme il le veux, car chacun devra s'occuper de son propre caca
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager