Bonjour,
aha... j'ai l'impression qu'on est peu nombreux à poster des messages (ou des questions) dans cette rubrique de Macbidouille ! ^^
Est-ce que tout le monde sait tout des languages web, ou est-ce qu'ils ont tous abandonnés ?
Enfin bref...
Ma nouvelle interrogation se porte sur l'architecture MVC, et plus particulièrement la hiérarchie des dossiers. Il en existe plusieurs, notamment celle de Symfony, qui est sans doute une référence :
Le back-end va exposer des services accessibles à travers des interfaces REST. Les URI REST obéissent à des règles fortes: GET serveur/appli/version/resources/identfiant ou PUT ou POST ou DELETE ou UPDATE, ce sont les verbes HTTP de base qui supportent la sémantique des actions
https://blog.wishtack.com/api-rest-bonnes-pratiques-et-securite/
Note: Il peut y avoir plusieurs domaines (ou modèles), le domaine de la BD n'est pas forcément celui de l'appli, et la présentation d'un objet peut demander des infos propres à ce besoin qui n'ont pas besoin d'aller dans la BD. On peut souhaiter avoir des fonctions de "mappage" qui permettent de convertir d'un domaine ou modèle vers un autre.
J-P
Hum... Je te remercie Jaypee, mais je crois que je vais avoir besoin d'un traducteur là... ! ...ou d'une aide supplémentaire...
car je ne sais pas si tu as voulu répondu à ma question, mais (et je te remercie quand même beaucoup pour cela !), tu m'en as apporté d'autres !!!
Mais j'essaie effectivement de trouver des bonnes pratiques (prenant en compte différent aspect : sécurité, côté pratique, modularité, clarté et pérennité de l'architecture pour un environnement multi-app)
- Me conseilles-tu d'associer une architecture MVC et des URI REST ?
- Est-ce compatible ?
Merci encore.
Oui, les REST APIs sont l'archi préférée des applications Internet en général.
Si on veut découpler l'interface utilisateur du back-end, c'est l'option à choisir.
Pourquoi dissocier? Permettre tous les types de clients
- Desktop PC/Mac
- Web
- IOS/Android...
Le back-end est une appli indépendante, c'est elle qui connaît les sources de données, et elle expose des REST APIs. Il existe des frameworks spécialisés dans les APIs REST. Par exemple Vapor 2.0 en Swift si on veut rester dans ce contexte, ou RubyOnRails ou Flask en Python (très simple)
L'autentification et les Roles/Permissions sont fournies par d'autre API REST, d'autres services spécialisé.
Le front-end est une appli MVC qui consomme les APIs REST qui sait manipuler le JSON qui remplace largement l'XML (en fait il ne remplace pas, on a le choix)
Le conseil, rester simples mais coller aux principes de REST et au format recommandé des URI
J-P
Bonjour,
Merci à tous pour vos réponses.
Une chose que je n'ai pas précisé, c'est ce que j'utilise comme language : principalement du php avec des classes, du jquery et des requêtes ajax sur une base mysql. Et effectivement bootstrap, pour une mise en forme rapide. Peut-être qu'à l'avenir, j'essayerai de développer des apps "tout javascript" pour pouvoir les porter vers iOS/Android (et à ce moment, j'opterai peut-être pour angular/cordova...), mais mise à part cela, je n'envisage pas plus complexe !
En tout cas, oui... je comprends bien l'utilité d'avoir une hiérarchie claire de dossiers pour s'y retrouver... et que la hiérarchie est surtout là pour aider le développeur.
Donc pour en revenir à ma question de base, devrais-je, selon vous, séparer mes apps de cette façon :
Les classes du modèle sont souvent utilisées dans plusieurs vues, donc je les mets dans un répertoire au niveau de l'application.
Une vue et son contrôleur sont en général implémentés dans un fichier chaque, donc les mettre dans des répertoires spécifiques alourdit l'arborescence du projet.
Il te manque un répertoire pour les services qui implémentent toutes les fonctions communes et transverses comme par exemple la persistence de ton modèle en BDD.
De la doc en français sur Silex, le framework PHP basé sur Symphony pour exposer des interfaces REST
https://openclassrooms.com/courses/evoluez-vers-une-architecture-php-professionnelle
J-P
Bonsoir,
Désolé, j'ai mis du temps à répondre à vos dernières remarques car j'ai essayé de me former à Silex, Composer, Twig... selon les recommandations de Jaypee avec les cours d'openclassrooms. (Merci d'ailleurs à lui !)
J'ai lu la totalité de ces cours très intéressants, mais... en faisant des tests en parallèle sur mon serveur, j'ai été bloqué à l'itération 9. N'étant pas familier avec les namespaces et les messages d'erreur de Silex, je ne comprends pas pour quelles raisons j'ai ce message d'erreur tenace :
Salut,
Je ne voudrais pas te décourager, mais utiliser un framework sans comprendre comment il fonctionne ne va pas t'aider bien au contraire. Ce sont aujourd'hui de véritables usines à gaz, et la plupart sont conçus pour construire des projets de "grande envergure".
Il existe des micro frameworks bien plus simples et faciles à appréhender que les mastodontes symfony, zend, laravel etc. Si par exemple le framework que tu compte utiliser est composé de 50 ou 100 fois plus de fichiers que le nombre de pages de ton application web, il faut sérieusement se poser la question de la pertinence de l'utilisation de ce framework.
Pour ton problème de message d'erreur la solution se trouve sur github, enfin le problème est référencé, j'ai pas tout lu : https://github.com/silexphp/Silex/issues/1621
Je ne pense pas qu'on puisse qualifier Silex de micro framework, enfin tout dépend de ce qu'on appelle un micro framework.
Un "micro framework" pour moi c'est plutôt http://flightphp.com/ qui est un framework qui se résume à une quinzaine de fichiers, rien à voir avec Silex.
Propulsé par Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)