Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 9 sur 13 PremièrePremière ... 5678910111213 DernièreDernière
Affichage des résultats 161 à 180 sur 256
  1. #161
    Futur Membre du Club
    Inscrit en
    décembre 2005
    Messages
    34
    Détails du profil
    Informations forums :
    Inscription : décembre 2005
    Messages : 34
    Points : 15
    Points
    15

    Par défaut

    Citation Envoyé par Molos Voir le message
    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... ?

  2. #162
    Expert Confirmé Sénior
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    2 916
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 2 916
    Points : 5 960
    Points
    5 960

    Par défaut

    Citation Envoyé par david drapeau Voir le message
    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

  3. #163
    Expert Confirmé
    Avatar de berceker united
    Profil pro
    Développeur informatique
    Inscrit en
    février 2005
    Messages
    3 143
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2005
    Messages : 3 143
    Points : 3 986
    Points
    3 986

    Par défaut

    Citation Envoyé par nabbo Voir le message
    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.
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  4. #164
    Membre émérite
    Homme Profil pro David DRAPEAU
    Directeur des systèmes d'information
    Inscrit en
    juin 2003
    Messages
    901
    Détails du profil
    Informations personnelles :
    Nom : Homme David DRAPEAU
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 901
    Points : 923
    Points
    923

    Par défaut

    Citation Envoyé par sekaijin Voir le message
    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.
    Consultant International OpenERP - python/xml/postgreSQL
    Expert PHP/MySQL
    Toujours à l'écoute du marché : Surtout en Suisse ! ;-)

  5. #165
    Futur Membre du Club
    Inscrit en
    décembre 2005
    Messages
    34
    Détails du profil
    Informations forums :
    Inscription : décembre 2005
    Messages : 34
    Points : 15
    Points
    15

    Par défaut

    Citation Envoyé par david drapeau Voir le message
    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" ?

  6. #166
    Futur Membre du Club
    Inscrit en
    décembre 2005
    Messages
    34
    Détails du profil
    Informations forums :
    Inscription : décembre 2005
    Messages : 34
    Points : 15
    Points
    15

    Par défaut

    Citation Envoyé par berceker united Voir le message
    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.

    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 )?

  7. #167
    Expert Confirmé
    Avatar de berceker united
    Profil pro
    Développeur informatique
    Inscrit en
    février 2005
    Messages
    3 143
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2005
    Messages : 3 143
    Points : 3 986
    Points
    3 986

    Par défaut

    Citation Envoyé par nabbo Voir le message
    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é
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  8. #168
    Membre émérite
    Homme Profil pro David DRAPEAU
    Directeur des systèmes d'information
    Inscrit en
    juin 2003
    Messages
    901
    Détails du profil
    Informations personnelles :
    Nom : Homme David DRAPEAU
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 901
    Points : 923
    Points
    923

    Par défaut un exemple simplifié

    Citation Envoyé par nabbo Voir le message
    (...)
    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");
        }
    }
    Consultant International OpenERP - python/xml/postgreSQL
    Expert PHP/MySQL
    Toujours à l'écoute du marché : Surtout en Suisse ! ;-)

  9. #169
    Futur Membre du Club
    Inscrit en
    décembre 2005
    Messages
    34
    Détails du profil
    Informations forums :
    Inscription : décembre 2005
    Messages : 34
    Points : 15
    Points
    15

    Par défaut

    Citation Envoyé par berceker united Voir le message


    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é
    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 ?

  10. #170
    Futur Membre du Club
    Inscrit en
    décembre 2005
    Messages
    34
    Détails du profil
    Informations forums :
    Inscription : décembre 2005
    Messages : 34
    Points : 15
    Points
    15

    Par défaut

    Citation Envoyé par david drapeau Voir le message
    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");
        }
    }
    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 ?

  11. #171
    Expert Confirmé
    Avatar de berceker united
    Profil pro
    Développeur informatique
    Inscrit en
    février 2005
    Messages
    3 143
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2005
    Messages : 3 143
    Points : 3 986
    Points
    3 986

    Par défaut

    Citation Envoyé par nabbo Voir le message
    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 ?
    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.
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  12. #172
    Membre régulier Avatar de Rizzen
    Profil pro Bertrand Merlier
    Inscrit en
    janvier 2008
    Messages
    112
    Détails du profil
    Informations personnelles :
    Nom : Bertrand Merlier
    Âge : 29

    Informations forums :
    Inscription : janvier 2008
    Messages : 112
    Points : 86
    Points
    86

    Par défaut

    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.
    Java'ldire à tout le monde

  13. #173
    Futur Membre du Club
    Inscrit en
    décembre 2005
    Messages
    34
    Détails du profil
    Informations forums :
    Inscription : décembre 2005
    Messages : 34
    Points : 15
    Points
    15

    Par défaut

    Citation Envoyé par berceker united Voir le message
    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) ?

  14. #174
    Expert Confirmé
    Avatar de berceker united
    Profil pro
    Développeur informatique
    Inscrit en
    février 2005
    Messages
    3 143
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2005
    Messages : 3 143
    Points : 3 986
    Points
    3 986

    Par défaut

    Citation Envoyé par nabbo Voir le message
    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
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  15. #175
    Expert Confirmé
    Avatar de berceker united
    Profil pro
    Développeur informatique
    Inscrit en
    février 2005
    Messages
    3 143
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2005
    Messages : 3 143
    Points : 3 986
    Points
    3 986

    Par défaut

    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
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  16. #176
    Futur Membre du Club
    Inscrit en
    décembre 2005
    Messages
    34
    Détails du profil
    Informations forums :
    Inscription : décembre 2005
    Messages : 34
    Points : 15
    Points
    15

    Par défaut

    Citation Envoyé par berceker united Voir le message
    A titre personnel, j'applique le type de variable seulement pour des cas précis.
    $objMonObjet, $collMaCollectionObjets,$arrMonTableau.
    Citation Envoyé par berceker united Voir le message
    (...)
    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 ?

  17. #177
    Expert Confirmé
    Avatar de berceker united
    Profil pro
    Développeur informatique
    Inscrit en
    février 2005
    Messages
    3 143
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2005
    Messages : 3 143
    Points : 3 986
    Points
    3 986

    Par défaut

    Citation Envoyé par nabbo Voir le message
    c'est moi ou tu te contredis ?
    C'est toi

    En faite je parlais de :
    Code :
    1
    2
    3
    4
    <?php
    class objMonObjet{
    }
    ?>
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  18. #178
    Membre confirmé
    Inscrit en
    septembre 2004
    Messages
    214
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 214
    Points : 251
    Points
    251

    Par défaut

    Citation Envoyé par USA Mike Voir le message
    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à).

  19. #179
    Membre Expert

    Homme Profil pro
    Inscrit en
    janvier 2004
    Messages
    1 244
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2004
    Messages : 1 244
    Points : 1 352
    Points
    1 352

    Par défaut

    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.

  20. #180
    Membre confirmé
    Inscrit en
    septembre 2004
    Messages
    214
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 214
    Points : 251
    Points
    251

    Par défaut

    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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •