DATASOURCE : ABSTRACTION DE DONNÉES
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
-
11 déc. 2006 à 09:16
guill76 Messages postés 193 Date d'inscription mercredi 24 août 2005 Statut Membre Dernière intervention 3 juin 2016 - 18 déc. 2006 à 23:59
guill76 Messages postés 193 Date d'inscription mercredi 24 août 2005 Statut Membre Dernière intervention 3 juin 2016 - 18 déc. 2006 à 23:59
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/40655-datasource-abstraction-de-donnees
https://codes-sources.commentcamarche.net/source/40655-datasource-abstraction-de-donnees
18 déc. 2006 à 23:59
Pour le pear je ne l'ai jamais utilisé mais pour appuyer ce que dit malalam, je viens de me faire (aujourd'hui) une petite adaptation d'un de mes codes (un editeur de tag mp3) au framework prado que je suis en train de décortiquer. Eh bien pour produire une simple datagrid (c'est à dire une simple grille html liée à un simple tableau php alimenté lui même par une source de données, dans mon cas, un répertoire de fichiers) tu dois instancier un nombre incalculable de classes ascendantes (certes c'est automatique mais ..):
D'abord le composant application qui appelle un gestionnaire de service qui appelle le gestionnaire de template puis le gestionnaire de composants applictifs puis tous ses composants 1 à 1, du validateur jusqu'à la datagrid en passant par des composans intermédiaires (parseurs de texte avec reg exp,parseur xml,editeur de code html,composants html simples et complexes, editeur de scripts clients,etc.. ): ça prend 10 fois plus de temps à charger que de charger ces propres classes (qui sont en plus tout aussi réutilisables)
Un framework comme prado est gigantesque mais son exploitation demande un serveur ultra performant pour optimiser les requêtes utilisateurs. Il reste donc reservé à une prog industrielle et ne peut se développer qu'avec du matériel puissant: Mon PC, lui, malheureusement, il fait la différence.
Dans l'absolu tu as peut être raison mais pour bien comprendre les choses il faut à mon avis savoir à tout prix comment, toi, tu peux ou tu pourrais les développer.
18 déc. 2006 à 10:28
je vais te répondre : je suis développeur web professionnel. Pour ma part, j'utilise, au contraire, le moins possible de packages pear ou autres, déjà tout fait. Et la raison est simple : je préfère passer un peu plus de temps au départ, et beaucoup moins au fil du temps. Quand on développe soi-même ses packages, on les dimensionne selon nos besoins, déjà, plutôt que de se trimballer un package énorme, que l'on utilise qu'à 10%. De plus, quand on a des modifications, des évolutions à apporter, c'est bien plus rapide quand pon doit les apporter sur un code que l'on a développé soi-même : on ne doit pas se taper tout le package pour essayer de comprendre comment il fonctionne, pour pouvoir y ajouter ce qui nous manque. On a un contrôle total, en clair. Et c'est important...tant au niveau des évolutions, que de l'optimisation et de la sécurité.
18 déc. 2006 à 07:08
Pourquoi veux-tu réinventer ce qui existe déjà. Regarde PEAR et ses différents modules, ils correspondent à ce que tu fais et le tout est Open Source.
Mais ceci dit je serais pas encore capable de faire ce que tu fais donc ce n'est pas du tout une attaque personnel mais plutôt une interrogation que j'ai depuis longtemps .Je suis développeur et ma devise est : en faire le moins possible si ça existe à coté et que c'est bien fait.
En tout cas beau travail quand même !
11 déc. 2006 à 20:47
11 déc. 2006 à 20:29
Pour la classe d'erreur, oui j'aurais peut être pu dériver la classe exception de php5 , mais bon l'idée de faire une classe statique m'est venue sans trop réfléchir. Y'a -il réellement des inconvénients à employer cette méthode? je ne sais pas.
Sinon en relisant j'ai vu 2 petites c...... dans mon code, je corrige.
11 déc. 2006 à 09:16
pas trop le temps de mater en détail, mais déjà, l'idée est bonne! C'est la base même de la POO. Je travaille une structure similaire à mon taf, avec des objets documents, dérivant d'une classe abstraite définissant les méthodes communes à tous types de documents (email, pdf, lettre, etc...).
Par contre, je ne suis pas forcément d'accord avec ta méthode pour lever les erreurs, mais bon...pourquoi pas.
Ca manque aussi, globalement, de vérifications, à mon sens.
Mais c'est quand même pas mal :-)