Bonjour!

Je suis actuellement en train de développer un projet en PHP5 objet avec une architecture n-tiers et souhaiterai savoir si il est judicieux de programmer la partie interface (contenant les formulaires) dans un paquetage (donc que chaque page soit une classe) ?

J'espère avoir exposer mon problème assez clairement!

Merci de votre aide!

Newt

Bonjour,

D'après les retour d'expérience que j'ai, le fait d'utiliser la POO pour la partie interface, ralentit énormément l'application.

Attends d'autres avis, mais personnellement je n'opterai pas pour la solution "tout objet".

À 100% d'accord pour l'accès au données et la couche métier mais pas l'interface.

C'est ce que je pensais, mais comme pour l'instant mon projet ne tourne qu'en local je ne vois pas vraiment de grande différence!

Si j'avais programmé pour moi j'aurai développé l'interface sans objet mais mon projet est avant tout basé sur l'objet, c'est la partie la plus importante et c'est donc pour cela que je me posais la question.

Maintenant si vous me conseillez plutôt une interface sans objet, je pense que se sera la solution pour laquelle je vais opter!

J'attend donc d'autres avis, en tout cas merci du tiens Ajoloca!

Re,

Même en local, tu peu simuler une montée en charge (bien entendu, elle n'aura pas grande valeur) mais ça te permettra de te faire une idée.

Pourrais tu m'indiquer comment faire?

Merci!

Re,

Regarde du coté de JMeter et OpenSta, des outils java gratuits.
Tu as aussi une version d'évaluation de NeoLoad dans ce site

Tu as aussi Tsung (pour Tsunami)

Regarde du coté de JMeter et OpenSta, des outils java gratuits.

Petite précision :

OpenSTA is a distributed software testing architecture designed around CORBA, it was originally developed to be commercial software by CYRANO.

Je signale qu'il n'y a aucun lien entre ce "Cyrano" et moi-même, il sera donc inutile de m'interpeler directement, je n'en connais pas plus que vous sur le sujet

D'après les retour d'expérience que j'ai, le fait d'utiliser la POO pour la partie interface, ralentit énormément l'application.

certes c'est un peu moins "optimal" en terme de perfs (mais faut pas exagerer, c'est quand meme pas la mort) , mais en terme de confort de développement et de maintien, y'a pas photo.

maintenant, le tout objet, faut pas exagérer non plus, php n'est pas java.
utiliser les objets pour les structures de données ou des fonctions particulières (abstraction db ou templates par exemple) oui,par contre programmer des pseudo méthodes main a la java est un non sens.

bon courage !

Bonjour.

Je développe actuellement un framework et un CMS (sans prétention aucune). J'ai choisis le tout objet.
Et c'est beaucoup plus pratique pour les interfaces. C'est très confortable et rapide (surtout lors d'une maintenance). Si tu as un système de cache derrière, alors ton système d'interface ne va consommer tellement de ressources que ça. Une fois de temps, pour créer le cache, et c'est tout.

Et il est parfaitement censé de programmer PHP dans l'optique Java (du moins vers C++ et Java). Je m'explique. Pour moi, PHP tend de plus en plus vers de la POO. PHP 5 peut très bien illustrer mes propos. Et pour moi c'est une chose merveilleuse. Les sites Web tendent également à devenir des applications à part entière. Il est donc logique d'avoir de la POO adaptée au Web nan ?

Pour résumer, si j'étais toi, je ferais un package interface

yopla !


scusez moi j'ai un peu de mal avec le concept de package interface... si quelqu'un peut m'expliquer le bousin ?

pour ce qui est du développement d'un framework, certes oui l'objet est tout indiqué (j'aurais meme du mal a comprendre comment on peut faire autrement).

je suis d'accord que développer dans une optique java deviendrait presque naturel tellement php tend à lorgner du coté de java (c'est un sentiment personnel que m'inspirent certains trucs du genre PDO, SPL et classes d'exception et l'api de reflexion... non pas qu'il s'agisse de les dénigrer, bien au contraire, mais bon... quelqu'un partage ce sentiment ?)

maintenant l'objet pour l'objet me parait un peu abusif tout de meme... enfin je dis ca, je dis rien, et j'en pense pas plus !

Merci pour vos avis!

Au niveau du test de montée en charge, j'ai essayé du coté de OpenSta mais j'ai un peu de mal avec la prise en main... Je suis donc en train de chercher une sorte de tuto en français afin de me donner une idée de ce que ca peut donner.

scusez moi j'ai un peu de mal avec le concept de package interface...

-> Justement moi aussi, c'est pourquoi je me suis posé la question de son réel interret... Mes classes appartenant à ce paquetage ne me servent en gros qu'a afficher le formulaire et à traiter les informations qui sont postées...

ah ca fait plaisir de voir que je suis pas completement à la ramasse !

personelleme,nt, pour ce qui est des formulaires, et de tout ce qui est affichage en fait, je passe par un systeme de gestion de templates. d'aucuns diront que c'est pas tip top en terme de perfs, mais question confort pour le programmeur, c'est vraiment le pied. de plus lié à un systeme de cache, ca devient beaucoup plus performant que le moindre systeme procédural, aussi propre et chiadé soit il. L'inconvénient peut devenir la quantité de stockage exigée suivant la taille du site.

ensuite pour traiter les formulaires, y'a pas vraiment de questions à se poser, un formulaire renvoie des données. tu sais ce que tu dois en faire, tu fais ta classe qui traitera ces données, en entrée comme en sortie.

enfin là je crois que chacun voit midi à sa porte en terme de logique de programmation... pis parfois y'a des cas particuliers qui impliquent une structure différente (parfois c'est compliqué la programmation ! pfff !)

bref amuse toi bien !

bonsoir,

voilà comment je traite les choses de mon côté.

J'ai un moteur de template qui me satisfait tout a fait. Depuis celui-ci je peux appeler des constantes, des variables, des fonctions, des méthodes propres à la library template, ou méthodes extérieurs à cette library. Donc complet. Bien sûr il faut programmer toutes les méthodes que l'on peut être susceptible d'appeler.

Ensuite j'ai mon système de cache qui enregistre les résultats (selon un méthode de trie : langue etc.).

Puis j'ai le package XHTML, qui me permet d'écrire des formulaires très simplement, selon le mode : on se fiche de la forme, on appelle juste les fonctions, et PHP créé un beau code bien organisé, id est accessible et standard (pour reprendre l'exemple des formulaires).

Et pour terminé, je traite les données POST avec mon package Http, pour sécurisé les données en fonction de leur provenance et/ou destination.


Ce qui -- pour moi -- constitue l'ensemble de l'interface. Je ne peux pas résumer ça dans un seul package. Chacun y apporte sa contribution.

Si on programme tout ça en pensant constament à la généralisation du problème, tu ne devrais pas rencontrer trop de difficultés. Peut-être comme le souligne Jules Petibidon, il y a toujours des cas particuliers. Mais quelques paramètres de plus dans une méthode, et le problème devrait être résolu


Je reste ouvert à toutes tes questions, et bonne chance (parce que les templates c'est chiant ).

Waow! Je connaissais pas le système des templates ça à l'air vraiment interressant! Mais bon je ne pense pas avoir le temps de l'adapter pour mon projet, ce sera pour le prochain surement!

Donc en gros dans mon paquetage interface j'ai une classe pour chaque page que j'appelle, et dans chaque classe j'ai en gros deux fonctions : une fonction qui permet d'afficher le formulaire et une qui permet de traiter les infos. Le constructeur quand à lui me permet d'initialiser les champs du formulaire et les attributs de ma classe sont les noms de ces champs.

Je ne vois donc pas l'interêt de faire cela car c'est créer des objet "pour créer des objets". Si vous me dites que ça ne ralentit pas spécialement l'application je pense que je vais laisser comme ça. Maintenant si vous avez d'autres avis ou remarques ça m'interresse!

En tous cas merci pour votre aide!

Newt