Reprise du message précédent :

Je rejoins FlorentG sur sa réponse, effectivement ce post est plus un brouillon de découverte du MVC qu'autre chose, mais faut bien commencer un jour. Et rien que le fait d'avoir la volonté de suivre ce genre d'architecture rend le code meilleur je trouve, même si évidemment, y a moyen de faire bien mieux. Enfin tu as tout à fait raison, finalement nous nous intéressons plus au concept qu'à des applications professionnelles sur ce post.
 
Par contre là où je ne suis pas d'accord, c'est sur la deuxième partier de ton message.

Ce que tu proposes, c'est assez proche de certains framework .net. Et franchement, ça produit un code bien à chier. Je pense notamment à un framework payant proposant des modèles cinématiques, le consultant .net de la boîte s'en servait au final jamais et passait son temps à aller corriger le merdier de code obtenu en l'utilisant. Mais ça permettait aux débutants de produire un truc carrément plus correct que ce qu'ils auraient codé de leurs mains, ça je te l'accorde. Néanmoins, si les boîtes arrêtaient de faire bosser des stagiaires, y aurait pas ce genre de problème.
Et le wysiwyg, alors là laisse moi te dire tout le mal que je pense de ces méthodes pour concevoir les vues d'une application. Tu te retrouves avec un code incompréhensible, top pas optimisé, impossible à débugger. (et je ne relancerai pas un débat sur les moteurs de template ici, notamment celui "intégré" à .net, pour dire tout le mal que j'en pense )
 
Dans l'absolu, tu as raison, seul le métier devrait réellement être codé. Mais c'est bien connu, les informaticiens essayent de produire à chaque application un nouveau processeur en partant de silicium, au lieu de partir de composants électroniques existants
Mais y a une raison à ça : les composants existants ne sont pas encore à la hauteur, ou en tout cas, répondant difficilement à des besoins particuliers.

nargy> je vois plus la chose comme une appli qui génère du code (à partir de templates par exemples) bien fixe qui lui ne génère rien.

> du code bien fixe qui ne génère rien
À quoi sert-il dans ce cas? Par définition un code retourne et/ou transforme et/ou stocke des données.
 
> à partir de templates par exemples
Et bien, autant faire de belles fonctions bien commentées, mises dans des bibliothèques, voire un modèle objet complet.
 
Bref, séparation du code et des données. Si, je t'assure, tu peux tester tu en arrivera à la même conclusion.

l'approche MDE fonctionne comme ça : on modélise une appli à haut niveau (UML par exemple) et templates + outils de transformation génèrent du code.
 
Personnellement, sur les quelques applis "RDBMS driver" que j'ai fais que ce soit du web ou du client riche, je vois un sacré nombre de dénominateurs communs (affichage de table, édition, workflows, statistiques par exemple).  
Créer du code générique pour ce genre d'appli est plutôt long, risqué et nécessite de paramétrer à mort le code.En plus ça peut conduire à une perte de performance.
Générer du code spécifique permet de palier à ces défauts.
 
Les avantages sont la qualité du code : tu ne l'écris qu'une seule fois. En cas de mise à jour, tu regèneres ton appli.
Ex: Tu dois prendre en compte 3 tables en plus ? quelques clics ou lignes de XML, , regénération, hop c'est reglé.
 
Imagine une appli gérant une centaine de table. Tu dois faire des formulaires de saisie pour chacune, la seule solution c'est les templates : soit php pur, mais le code doit être suffisament générique, soit php + moteur de templates en plus, ça alourdit l'application je trouve.
 
Avec un outil de génération, tu génères un formulaire spécifique pour chaque table en 1 clic : temps de développment ridicule et performances optimales.
 
Pour l'architecture du code, c'est tout à fait possible de générer du code "MVC-compliant".

Je vois tout à fait ce que tu veux dire. J'ai déjà essayé. Pas en PHP, mais dans d'autres languages.
 
En plus il est très facile de faire ça avec un language script, mais au final tu est le seul à pouvoir maintenir l'application. Celà necessite en effet quelqu'un qui ait à la fois les compétences nécessaires au niveau programmation, et qui de plus connaisse très bien le système de génération pour pouvoir le faire évoluer. Saurais-tu expliquer rapidement le fonctionnement de ton application à un novice?
 
Un MVC classique, une architecture objet bien conçue, et même un système de bibliothèques de fonctions, te permettent d'obtenir les mêmes résultats et dans certains cas de meilleurs performances (si, si!), avec un gain notable en coût de maintenance. Confère: PHP est un language de template HTML.
 
Tu as l'air bien enthousiaste aussi je ne compte pas te convaincre, je pense que tu te convaincra toi-même.
 
J'adore PHP, et je connais aussi ses limites. Un MVC en PHP est déjà très ambitieux.

En fait je ne parle pas de php, pour moi c'est quelque chose pour s'abstraire du langage de programmation. D'ailleurs c'est à ça que servent les outils de modélisation UML : on modélise un système (une application ou même une architecture matérielle) et les outils de transformations par étapes successives génèrent le code source correspondant au modèle (ou le code source pour simuler l'architecture matérielle). Cela permet de se focaliser sur les concepts du système et pas sur son implémentation. Néanmoins, l outil de modélisation doit permettre de modéliser un maximum de chose, sinon on est vite obligé de coder un peu à la main. Je bosse sur un outil dans ce genre en ce moment, je verrais bien dans quelques mois si c'est effectivement une voie sans issue.
 
Tu dis quetu as déjà essayé, quels problèmes as tu rencontré?

Pas besoin de "MDE" pour ça e.g., Rails Migrations & pattern ActiveRecord

Sauf que la partie la plus longue du développement d'un formulaire, c'est sûrement pas de créer 3 inputs et un select, c'est de les positionner dans la page et de créer toute la partie de validation (serveur & client), et rien que la spécification exacte de la validation du formulaire demande largement plus de "un seul clic"

le MDE/MDA permet plus que les "mises à jour facile", c'est très haut niveau, pour s'abstraire du code => Les architectes pour le modèle, les hackers pour l'implémentation. Après, si derrière le modèle, l'implémentation en ruby est plus simple qu'en PHP, c'est encore mieux.  
L'objectif, c'est le développement rapide, abstrait des contraintes techniques et focalisé sur les concepts de l'application.
 
De plus, rien n'empeche de retoucher le code derrière, le code généré n'est pas forcément illisible.
 
Quant à la présentation, on peut trouver facilement également des dénominateurs communs dans la présentation de formulaires (d'édition,d'impression, de listings), et puis pour le web CSS permet de ne pas mélanger présentation et traitement.
Si l'appli est modélisée assez précisément, il n'est pas très difficile d'agencer les widgets graphiques en fonction d'un ordre par exemple, de la largeur de texte maxi, etc
 
Il faut voir cela sur le long terme, la création du framework est plutot ardue, mais après quand quelques clics suffisent à avoir une appli, la rentabilité est maximale.

Tu m'as l'air bien idéaliste sur le sujet du web, des CSS et des formulaires

pourtant la (relative) expérience que j'ai du développement d'applis web m'a tout de même conduit à conclure que je faisais souvent la même chose, même pour des formulaires et des CSS.

Et c'est dommage. Si tu est toi même blasé, comment fera-tu pour retenir l'attention de l'internaute, pour le faire rester plus longtemps sur tes sites?

Exact, et celà rejoint ce que je dis plus haut: 30 formulaires identiques c'est bien, 30 formulaires interactifs, au sens où chaque formulaire a été pensé pour simplifier l'utilisation du site et le rendre attractif donc possèdant des caractéristiques propres non factorisables, c'est mieux.

Je te l'ai déjà dit: au résultat tu as un code à la limite du maintenable. Si tu as à revenir sur ton application, je suis sûr que tu aura des difficultés toi même à le modifier. La solution étant de faire une tonne de doc, ce qui te fera perdre du temps.
 
Coder dans les normes, de façon <<standard>>, permet d'éviter ce genre d'inconvénients.
 
Encore une fois, imagine que quelqu'un ai à reprendre ton appli (tu est en vacances, tu a changé de bouleau, tu t'occupe d'autres projets de plus grande envergure etc...). En combien de temps un novice peut-il raisonnablement maîtriser le système?
 
La dernière fois que ça m'est arrive, de devoir reprendre un code ... disons tout crade ... et bien même si j'avais la doc complète il était plus facile pour moi de recommencer à zéro la librairie plutôt que de la modifier pour de nouveaux besoins.

Ca j'aime pas trop au final. Faut se poser la question "suit-je développeur, ou clicketeur professionnel" ?
 

Genre du scaffolding ouais. Là ça peut être intéressant pour avoir une base : tu génères un formulaire à partir du schéma de base de donnée, que tu modifies après un peu pour mieux refléter le besoin.  
 

P'tain ouais, ça m'arrive en ce moment avec osCommerce : je m'amuse à le réécrire en partie

Plus je lis plus j'ai mal à la tête je ne pige pas . Bref je ne chercher pas tellement à comprendre.  
Je relève juste une chose. Actuellement, je developpe une appli et c'est codé en objet. Je pense que j'ai pas fait du boulot de "chien malade" car je suis arrivé à un point, que je souhaitais, l'appli est découpé en module mais possède la même structure, protocole objet. En gros, pour qu'un développeur puisse comprendre l'application il suffit qu'il regarde qu'un module pour qu'il comprenne comment fonctionne le reste puisque je garde le même protocole objet.  
Je sais pas si ce que j'ai fait est un MCV mais je pense qu'elle s'y approche.  
 
Source de données.  
c'est une sorte de package qui communique avec les base de données comme l'application peut tourner sur plusieurs base de données j'ai du séparé en deux.  

• Data : un package à un niveau plus haut qui est là pour receptionner les demandes. le demandeur n'est pas au courant de la provenance de la source de données. Ce package ne retourne que des objets.
• - le niveau le plus base possède toutes les requêtes SQL. Il y a autant de requête que de base de données qu'il peut gérer. Selon le type de base de données il prend la requête adéquoite. Seul Data à le pouvoir de communiquer avec lui.

• Le metier.  

C'est un package qui contient tous le coté métier de l'application. Il sait ce qu'il demande mais il ne sait d'où, il ne sait pas comment l'afficher c'est pas son affaire. Il ne connait que l'objet.
 

• L'affichage.

Ce packet n'est là que pour afficher le contenu des objets. de la je peux choisir la sortie pour la même source d'information objet ou collection d'objet. Sortie en HTML ou XML.
 
Controleur.  
C'est le chef d'orchestre. Il est là pour que récupérer les informations et le donner à l'affichage.
 
 
Au finale, sur une page php qui doit afficher un liste d'éléments j'affiche ceci.  

Scénario.  
-Le controleur va demander à Data de récupérer les éléments.
-Data va regarder le fichier XML de configuration, de la, il sera que, par exemple, c'est sur SQLServer. Il va instancier l'objet requete possedant la methode getAllElement. Data execute la requete place ce beau monde dans l'objet Element. Il donne l'information à controleur.  
-Controleur, dans l'objet ShowListe, récupère la collection d'objet et le donne à Affichage.
-Affichage va lire cette collection d'objet et génère le code HTML le retourne à controleur.
-Controleur le retourne dans la methode ShowListe().
 
C'est un MVC ou c'est de la merde de corbeau

C'est un beau mix avec du MVC dedans

Bon ben ça va alors ça me rassure un peut   . J'ai oublié qu'il y a un controleur par module qui lui hérite d'une classe controleur. Idem pour data et cie. Ainsi pour passer sur un autre module je peux recopier la structure et hope je developpe plus vite.    
Le plus dure était de gérer le multibase de données de telle sorte que ça soit transparent. Il y a juste à écrire le reqête si elle est particulière ainsi l'application n'est pas totalement dépendante de la structure de la base de données et même entre elle. Ce que je veux dire c'est qu'il est possible que la version SQL Server n'est pas la même structure que Mysql. Afin d'éviter de faire des reqêtes trop générique passe partout.

+1, j'aime pas les requêtes SQL soit-disant passe partout, mais qui passe jamais  

Je re sur la discussion à propos des outils de génération de "code" (de pages html...) :
 
je comprend pas l'intérêt de tels dispositifs quand on s'est emmerdé (amusé?) à mettre en place et coder un joli p'tit système en MVC. L'idée du clic unique (ou magique) m'a jamais convaincu, car je mets au défi quiconque de configurer quoi que ce soit sur un pc en 1 seul clic
 
C'est dommage de s'arrêter là quand tout le reste est bon... Je vois pas le problème s'il faut utiliser/créer des templates maison - légers mais adaptés -, et je vois surtout pas le gain en temps et en ressources à employer de telles méthodes automatisées, pré-cuites puis réchauffées, et sur le résultat desquelles il faut ré-intervenir un nombre aléatoire de fois à un nombre aléatoire d'endroits.
Après je peux me tromper, jusqu'a présent j'ai pas vraiment eu l'occasion de travailler dans des environnements très "orienté qualité" Cependant ça me paraît un peu absurde d'avoir fourni les + gros efforts en amont pour tout compromettre par "gain de temps" et finalement perdre beaucoup en souplesse.
 
Sur l'idée du MMVC, je comprend pas la distinction entre Métier et Modèle, lequel est issu duquel ? Sont-ils mis en parallèle ?? Le plus générique ? Le plus proche des données ?
 
Merci d'avance

 
Je suis daccord sur ton point de vue et je pense que c'est pour cela que inconsiament j'ai pas voulu faire quelque de trop générique car comme tu le décris c'est que nous sommes jamais à l'abri d'un cas particulier. et lorsque nous faisons de particularité ben ça remet en cause le travaille générique.

Oula.... le cas générique prends en compte au moins 2 cas particuliers, et n'est là que pour factoriser ce qui serait autrement copié/collé.

axelazerty> c'est vraiment bidon ce que tu racontes, moi j'ai une IA qui code à ma place, elle s'appelle sandra et c'est une grosse c

bidon ? va te renseigner un peu sur UML, et MDE/MDA...

l'UML c'est pas les jolis graphiques qu'on fait une fois que le projet est fini pour que les dissaïdors aient une jolie doc

Non c'est avant pour que le client sache de quoi tu parles et normalement la doc existe avant que le projet finisse puisque tu es censé suivre un cahier des charges  

C'est le doux rêve que je faisais avant chaque projet... Une belle doc, de beaux diagrammes UML, toute les classes & fonctions pré-documentée et désignées...
 
Sauf que ça foire à chaque fois. Je trouve extrêmement difficile le fait de pré-designer une appli entière. A chaque fois que j'ai tenté ça, ça se finissait en un triple refactoring globalisé (comprenez recommançage trois fois).
 
Alors maintenant je me fait plus chier comme ça. Je désigne vaguement, je ne fais que tracer les grandes lignes. Exemple pour le MVC ici : mon design initial, c'est un pauvre diagramme même pas fini, un peu bancal, avec encore la palette de couleurs d'Office 2007 pour avoir des couleurs jolies :
 

 
Ensuite, je fais une première implémentation + tests unitaires
 
Start:

• Je refactorise.
• Je refactorise aussi les tests unitaires s'il le faut

if(++iterationNumber < 4) {
  goto Start;
}
 
Et là j'me retrouve avec quelque chose de très bien. Maintenant au lieu de recommencer toute l'appli, je développe par petits blocs. Parfois je commence par écrire les tests, puis l'implémentation (Test Driven Development). Ca permet de voir direct les problèmes d'implémentation, et de voir si c'est pas trop relou à coder. D'ailleurs je crois que je vais continuer comme ça... TDD ouais. Faut que je voye du concret cash, pas des schémas...
 
Qu'en pensez-vous ?

Que pour mon taf j'ai perdu un mois à faire de jolis diagrammes UML pour les foutre à la poubelle vite fait.
Je suis pour
(enfin là ton diagramme, c'est vraiment juste pour faire beau  ^^)

Il ne faut pas confondre UML pour "faire beau" et UML pour développer.
Si c'est juste pour avoir un schéma de l'archi de l'appli, autant prendre des outils comme visio. UML est à utiliser dans une approche dirigée par les modèles pour crééer l'appli, pas pour la documenter.

ça c'est très beau, mais on est justement en train de dire qu'on trouve ça à chier l'UML pour développer une appli. Tu ne peux pas appréhender correctement et dans les détails l'ensemble de ton application par ce moyen. Y a rien de tel que les mains dans le cambouis.
Ca sert à débroussailler, rien de plus.

tu connais mal MDA à mon avis.

tu es développeur pour de vrai ? ou tu es manager plutôt non ? parce que tu m'as l'air bien idéaliste.
(c'est pas du tout une critique hein, mais tes propos ressemblent plus à ceux d'un mec qui supervise des développeurs, je pose la question donc)
Et par rapport à ton message d'avant, je te rappelle que l'UML (en tout cas les premiers types de diagrammes) a justement été crée pour permettre le dialogue avec des non-développeurs, donc le "UML est à utiliser dans une approche dirigée par les modèles pour crééer l'appli, pas pour la documenter." ça me paraît on-ne-peut-plus-faux

L'uml dans un projet permet surtout de répondre à cette question.  
"Qui fait quoi à qui" et non pas "comment il faut pour qu'il" ça c'est le dévelppeur. Il est vrai que l'uml permet d'avoir une certaine approche face au projet mais pas de la finaliser.

Vous n'utilisez UML que pour l'organisation du projet, alors qu'il permet beaucoup plus.
Renseignez vous sur MDA, la modélisation/métamodélisation si ça vous intéresse.

Tiens, je découvre seulement ce topic ...
 
C'est intéressant, mais ça remet un peu en question mes méthodes Quoique dans les grandes ça tend à rejoindre un peu ce que je fais ...
 
Mais pas aussi "poussé" je dirais. En tout cas je ne connaissais pas ça comme ça, je vais continuer à me documenter sur la question.
 
Merci pour le topic

Moi mon plus gros problème dans tout ca c'est le controller où le code est tout bordélique... Vous l'organisez comment vous ?
Pour l'instant j'en suis à "switch($action) { ... }"
 
Mais ya pas mal de bordel au niveau du traitement et gestion des données utilisateurs notamment (quand on récupère des $_POST par exemple, avant l'ajout d'une news il faut tout bien vérifier, et chezmoi c'est dans le controlleur)
 
Du coup le controlleur est immense ! Et ca devient le bordel à la fin.
 
Bien, mauvais ? Quelqu'un à une bonne solution ?

front controller, et un controlleur pour chaque module ?

+1

Salut,
 
J'ai bien lu tout le poste mais je me pose des questions.
 
- Ou placer l'appel à la base ? la connection  
- Si on procède par class comme cela, sur un formulaire d'inscription le passage de parametre va etre extremement long en fonction des input du formulaire
- Si j'ai une class qui ajoute en base + une class qui affiche un message de bienvenu reprenant des infos issues de la base, comment faire ?

Ca je sais pas encore Mais à priori faut une classe quelque part qui puisse fournir des connexion à la demande
 
 

Comme ça doit passer par POST, pas de probs
 

Tu définis une action dans ton controller qui va ajouter les donnée en base via le model, puis qui va chercher la view correspondant au message de bienvenue

Je viens d'essayer, la gestion des couches est tout de meme pas évidente à placer dans une appli assez complexe avec pas mal de requete etc.

Ouais c'est sûr que ça fait pas mal de changement. Ca peut être long de reprendre totalement une application

La gestion de 3 couches bien distinctes est tres bien, seulement on peut tres bien le faire via des fonctions plutot que des classes ?