Comment bien programmer en PHP ? [Débat]

[nabbo]

Envoyé par Molos

Pour nabbo, je suis dans le même cas que toi, et donc pour que mes méthodes ai accès à mon objet $db, j'initialise l'objet dans mon fichier cfg.php, qui me permet de mettre les paramêtres pour la base de données, et d'ouvir une connexion.

Ensuite, dès qu'une méthode à besoin de mon objet $db, je met un global $db et le tour ai joué, après je sais pas si c'est une bonne solution, mais en tout cas ça marche

oui, j'ai déjà fait ça dans un projet.

Mais je ne suis pas sûr que ça soit une bonne pratique.
Parce que ta classe ne peut pas être exportée dans un autre projet, à moins de s'assurer que l'objet de connexion à la base de données soit présent partout... ?

[sekaijin]

Envoyé par david drapeau

Il est très bien aéré ton code et même très clair. Donc pas besoin de commentaire supplémentaire. Il faut aussi que ceux qui te lisent cherchent à comprendre et ne pas les nourrir mais leur apprendre à jardiner.

Personnellement, je ne mettrais pas de classes dans le répertoire modele/ mais dans le répertoire include/. Et tout ce qui est classes et controlers seraient placés dans ce répertoire include/ car mes controlers sont programmés sous forme de classes.

non oublie le dossier include qui n'a pas de sens.
ça ne veux rien dire include

moi j'utilise ça

Code :

1
2
3
4
5
6
/application
   /controllers
   /model
   /views
/library
/public

/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

/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

[berceker united]

Envoyé par nabbo

j'essaie d'illustrer un peu.

Je ne me rappelle plus de la syntaxe de la phplib, donc on va improviser (flemme de regarder ) ...

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,

Code :

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;
      }
}
?>

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.

[zyongh]

Envoyé par sekaijin

non oublie le dossier include qui n'a pas de sens.
ça ne veux rien dire include

C'est une opinion que ne tient qu'à toi. include/ est utilisé depuis la nuit des temps de la programmation (je zappe l'asm et le basic), c'est à dire depuis C/C++ ! Et puis il y a toujours plusieurs façons de bien organiser une arborescence.

[nabbo]

Envoyé par david drapeau

Il est très bien aéré ton code et même très clair. Donc pas besoin de commentaire supplémentaire. Il faut aussi que ceux qui te lisent cherchent à comprendre et ne pas les nourrir mais leur apprendre à jardiner.

Personnellement, je ne mettrais pas de classes dans le répertoire modele/ mais dans le répertoire include/. Et tout ce qui est classes et controlers seraient placés dans ce répertoire include/ car mes controlers sont programmés sous forme de classes.

oui. l'histoire des répertoires, c'est juste pour illustrer ce qui se passe dans ma tête, et pour être sur de bien séparer tout ça.

est ce que tu pourrais montrer ce que ca donne en gros des "controleurs programmés sous forme de classe" ?

[nabbo]

Envoyé par berceker united

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,

Code :

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.

et comment tu te sers de la classe ?
où/quand tu l'appelles (par exemple dans les quelques fichiers que j'ai cités auparavant )?

[berceker united]

Envoyé par nabbo

et comment tu te sers de la classe ?
où/quand tu l'appelles (par exemple dans les quelques fichiers que j'ai cités auparavant )?

Dans mon cas personnel je l'utilise avant tout autre appelle de classe ayant besoin d'une connexion et je le diffuse.
En gros

Code :

1
2
3
4
5
$db = new db();
$m = new maClasse($db); 
ou 
$m = new maClasse();
$m->setDb($db);

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 :

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

Toute classe héritant de Maman pourront être arrosé par l'objet DB.
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é

[zyongh]

Envoyé par nabbo

(...)
est ce que tu pourrais montrer ce que ca donne en gros des "controleurs programmés sous forme de classe" ?

Code :

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");
    }
}

[nabbo]

Envoyé par berceker united

Code :

Toute classe héritant de Maman pourront être arrosé par l'objet DB.
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é

au moment ou tu crées une classe fille, tu écris juste :

Code :

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 ?

[nabbo]

Envoyé par david drapeau

Code :

je comprends pas ce que tu fais...
c'est l'équivalent de mon index.php ?

Code :

1
2
 
        $fileName = $this->_returnRequest['action'] ;

ca sert à quoi ?

[berceker united]

Envoyé par nabbo

au moment ou tu crées une classe fille, tu écris juste :

Code :

?

je trouve que c'est un peu pareil que d'avoir un global $db... non ?

Oui tu pourras utiliser l'objet $mydb dans la classe Fille. De point de vue organisation l'utilisation d'une variable global n'est pas terrible. Pour moi c'est presque tricher pour pas s'organiser. Prend la décision de dire qui doit faire quoi et ou il doit aller.

[Rizzen]

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.

[nabbo]

Envoyé par berceker united

Oui tu pourras utiliser l'objet $mydb dans la classe Fille. De point de vue organisation l'utilisation d'une variable global n'est pas terrible. Pour moi c'est presque tricher pour pas s'organiser. Prend la décision de dire qui doit faire quoi et ou il doit aller.

autre question...
si on reprend mon exemple d'affichage d'une liste d'utilisateurs

où / comment est ce que tu gères l'interaction de formulaires (ex : ajout d'utilisateurs) ?

[berceker united]

Envoyé par nabbo

autre question...
si on reprend mon exemple d'affichage d'une liste d'utilisateurs

où / comment est ce que tu gères l'interaction de formulaires (ex : ajout d'utilisateurs) ?

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

[berceker united]

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.

Code :

1
2
3
$intNbUser = 0;
$strName = 'Frippouille';
$boolIsConnected = true;

Cool vous avez indiqué le type mais à titre personnel cela ne sert pas à grand chose.

Code :

1
2
3
$nbUser = 0;
$Name = 'Frippouille';
$isConnected = 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.
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

[nabbo]

Envoyé par berceker united

A titre personnel, j'applique le type de variable seulement pour des cas précis.
$objMonObjet, $collMaCollectionObjets,$arrMonTableau.

Envoyé par berceker united

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

c'est moi ou tu te contredis ?

[berceker united]

Envoyé par nabbo

c'est moi ou tu te contredis ?

C'est toi

En faite je parlais de :

Code :

1
2
3
4
<?php
class objMonObjet{
}
?>

[Nicam]

Envoyé par USA Mike

PHP est un langage simple donc il est important que le code écrit soit simple aussi.

Bcp de gens codent comme si la ligne de code était payante.
Donc j'évite les profusions de function appelant de function qui appelle des fonctions..Etc

l'important dans une apli PHP, est qu'elle soit immédiatement accessible lors d'un débug ou lors d'une TMA.
L'optimisation du code n'est pas importante car l'évolution matériele (perf) permet de s'en passer : ça coute moins cher d'acheter un serveur avec un meilleur CPU/pluis de RAM que de payer quelqu'un 1 semaine pour venir reprendre le code de quelqu'un.

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

[Fladnag]

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.

[Nicam]

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