Quelle est la bonne architecture (soignée) dans la programmation d'un site Web simple, par exemple un carnet de contacts?


28

Lorsque je crée un site Web simple, par exemple un carnet de contacts où je peux ajouter, supprimer et mettre à jour des contacts, je crée un index.phpfichier où un utilisateur, s'il n'est pas connecté, est invité à entrer un mot de passe et s'il entre le bon mot de passe, il est attribué une session et peut faire certaines choses avec les contacts.

J'ai deux fichiers:

  1. Le premier ( contacts.php) correspond au code HTML à afficher. Au-dessus du code HTML, j'inclus le deuxième fichier et crée la classe.
  2. Le second ( contacts_class.php) contient toutes les méthodes d'ajout, de suppression et de mise à jour.

Je pense que ça va, mais quand il s'agit de mettre en œuvre un grand projet, comment dois-je le faire? Dois-je créer des dossiers pour chaque page et y mettre des fichiers (comme ci-dessus, HTML et classe), et comment dois-je le faire? Qu'est-ce qu'une architecture bonne et soignée pour la construction de grands projets que tous les autres programmeurs comprendraient parfaitement?

Réponses:


67

Vous avez soulevé une question très intéressante et fondamentale. La question concernant l'architecture de projet à grande échelle et l'organisation de la structure des dossiers (qui est secondaire à l'architecture).

Aujourd'hui, l'approche la plus courante pour construire l'architecture du framework CMS est l'utilisation du modèle MVC. Il y a quelques bons articles sur la construction de vos propres frameworks MVC, l'un d'eux est Build an MVC Framework with PHP .

MVC signifie Model, View, Controller. Vous pouvez appeler ces approches comme bon vous semble - MVC, HMVC, MVP. L'essentiel est d'isoler les composants individuels de votre système. Le "Controller" récupère les données du "Model" et les envoie à "View", qui rend le HTML final. Vous avez déjà implémenté le "V" dans votre contacts.phpet "MC" dans votre contacts_class.php. Vous avez donc isolé la vue du modèle et du contrôleur. Maintenant, vous pouvez facilement changer votre "Vue" en laissant les autres parties intactes.

Je ne vous suggère pas de suivre aveuglément le modèle MVC, MVP ou quoi que ce soit d'autre "MV". C'est une question de pertinence, d'efficacité et de goût.

L'application de site Web dynamique commune peut inclure des composants tels que:

  • Le point d'entrée, disons index.php
  • Les bibliothèques / classes d'assistance
  • Le routeur de requête
  • Les modules, composants ou contrôleurs
  • Le moteur de modèle ou peut-être des vues uniques

La véritable application Web peut inclure d'autres composants tels que des gestionnaires d'événements, des répartiteurs d'événements et des hooks, mais ce sont en fait des nuances. Eh bien, permettez-moi de le présenter comme je veux le présenter:

Le schéma de routine d'opération

La routine d'opération de cadre commun comme suit:

  1. La demande du navigateur est envoyée directement à l'exécutable / script du point d'entrée ( index.php).
  2. Le script du point d'entrée charge les bibliothèques d'assistance, les classes et effectue une initialisation supplémentaire de notre environnement de programmation.
  3. L'URL est transmise à l'instance de routeur de demande. Cette étape peut faire partie de l'étape 2.
  4. Le routeur de requête analyse l'URL et envoie l'opération à un composant, module ou contrôleur particulier.
  5. Le composant (ou contrôleur) traite la demande routée et envoie les données à la vue à restituer.

La structure de dossier de projet correspondante est illustrée dans le diagramme.

Je vous suggère d'étudier comment les autres cadres sont mis en œuvre. Les CMS / frameworks recommandés pour commencer sont CodeIgniter, OpenCart, Joomla 1.5 et Tango CMS.


3
Qu'avez-vous utilisé pour créer cette image? Très bonne réponse!
Mark Tomlin

3
Merci pour l'évaluation positive de ma réponse! J'apprécie vraiment cela! Cette réponse est entièrement le résultat de l'analyse de divers cadres d'applications Web open source, que j'ai menée plus tôt pour moi-même. Pour ceux qui s'intéressent à la façon dont l'image a été créée et au logiciel utilisé, l'image a été créée à l'aide d'Inkscape 0.48 et de GIMP 2.6.10. Aucun problème avec cela. Utilisez simplement deux calques: un pour les rectangles avec du texte, un pour les ombres (les rectangles noirs flous). Je suppose que tu comprends le reste?

Une question, pourquoi sépareriez-vous les contrôleurs «contacts» en 3 fichiers. Ne serait-il pas plus simple de les combiner en un seul contacts.php. Tout ce que vous avez à faire est de passer un paramètre d'action à partir du routeur. La même chose peut être dite pour les vues «contacts», à moins que votre vue ne mélange les modèles et la logique dans un fichier pour chaque action. Je ne fais pas beaucoup de dev en PHP (je travaille principalement en Python) mais j'espère que tous les frameworks n'utilisent pas cette approche. Sinon +1 pour une bonne rédaction.
Evan Plaice

2

Pour avoir une idée des questions à poser et des solutions disponibles, je recommande le livre Patterns of Enterprise Application Architecture de Martin Fowler. Vous pouvez vous faire une idée de ce qu'il y a dans le livre en lisant son site Web

Sachez que le livre est déjà assez ancien (en informatique) mais que de nombreux principes sont toujours valables ou vous devriez les apprendre à apprendre. (Cela avait-il du sens?)

(Logiciel) L'architecture est un sujet très large, ne vous attendez pas à une solution miracle mais toujours plus de questions et plus de doute jusqu'à ce que le temps et l'argent soient épuisés et que vous devez vous en tenir à la meilleure solution jusqu'à présent.


2

Tout d'abord, jetez un œil à un projet bien développé. Wordpress est un exemple très soigné de structure de code: il est simple à comprendre mais offre beaucoup de "plug". Wordpress est donc facile à estimer via "plug in".

Deuxièmement, un moyen très simple de vérifier votre architecture consiste à écrire un test unitaire. Par exemple, si la classe "Card Deck" a une méthode "shuffle ()", vous devez pouvoir créer un Card Deck de taille prédéfinie (par exemple 5 cartes 1,2,3,4,5), appeler shuffle et vérifier dans un résultat facile (id 1,4,2,5,3)

Vous devez pouvoir le faire sans instancier l'intégralité des classes de projet, et le test doit être très propre à lire.

Si vous ne pouvez pas le faire, vous devez ajouter des couches entre les classes, les restructurer, jusqu'à ce que vous obteniez un moyen facile de le faire.

Répétez ensuite cette étape pour toutes les classes principales de votre projet.

Dernier point mais non des moindres: une bonne architecture pourrait être "paresseuse" sur des classes pas si essentielles (c'est une question d'économie: les choses très bien conçues coûtent trop cher dans le monde réel).


1

MVC (Model View Controller) est une bonne architecture pour les projets à grande échelle: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Cependant, la question de savoir si d'autres programmeurs le comprendraient est tout à fait différente. MVC peut devenir complexe et est parfois exagéré pour les petits projets. L'un de ses avantages est qu'il évolue facilement.


C'est un modèle, pas une architecture.
halfdan

Je dirais qu'ils sont un dans le même cas dans ce cas. Comment différencieriez-vous les deux? Lisez également la toute première ligne de la page Wikipedia que j'ai publiée.
Chris Laplante

1
D'après mon expérience, MVC n'est pas complexe et est également très utile dans les petits projets. Je suis d'accord cependant, c'est un modèle et non une architecture entière.
Danny Varod

MVC est un modèle, pas une architecture en soi, mais il peut être considéré comme faisant partie de l'architecture. Et ce n'est pas si compliqué après tout.

1

Si je comprends bien votre question, vous parlez de la structure du dossier du projet et non essentiellement d'une architecture. Si ma compréhension est correcte, lisez la suite; sinon modifiez votre question ou mettez un commentaire et je modifierai ma réponse en conséquence.

Lors de la conception d'une application, après avoir répondu à certaines questions de base telles que (quoi? Et à qui?), Nous devons identifier les composants et les classer en fonction de la fonctionnalité \ des responsabilités. Il y a deux façons principales que je connais. Vous pouvez classer les composants en fonction de, utiliser les cas qu'ils gèrent (comme la connexion, la recherche, etc.) ou classer en fonction des ressources (objets ..). La première méthode est appelée orientée vers l'activité et la seconde est appelée orientée vers les ressources. Traditionnellement, la plupart des applications classent les composants en fonction des activités (car les concepteurs l'ont trouvé, facile lors du transfert d'un domaine problématique vers un domaine de solution) .Mais je m'égare.

Une fois que la classification des composants est identifiée, nous devons identifier la classification basée sur les niveaux. Une application Web typique aura un niveau de vue, un niveau de modèle et un niveau de contrôleur (MVC). Bien sûr, il pourrait aussi y avoir des applications plus complexes. (la plupart des applications du monde réel sont plus complexes que cela est simple).

Après avoir identifié ces deux taxonomies, je vais créer des dossiers de premier niveau identifiant chaque niveau. (UI, Controller, Services, Utils, etc.). Sous chaque dossier de haut niveau, je vais créer des dossiers enfants basés sur la fonctionnalité ou les ressources (Project - / EditProject - / SearchProject etc.). Idéalement, la classification fonctionnelle sera à plusieurs niveaux.


Je ne suis pas allé plus loin dans les différences entre la conception orientée vers les ressources et la conception orientée vers les activités. Outre la digression, je n'étais pas très sûr de la question. Mais personnellement, en ce qui concerne la clarté de la conception (la facilité avec laquelle un nouveau développeur peut comprendre les composants et la conception sous-jacents), l'architecture orientée ressources est meilleure. En regardant simplement dans la hiérarchie des dossiers, un développeur pourrait comprendre l'ensemble des ressources participantes et les sous-ressources et le fonctionnement de chaque ressource est également uniforme.

1

Il y a de bonnes architectures et de mauvaises architectures, mais il n'y a pas de balles d'argent. Une architecture doit être adaptée aux exigences actuelles et futures possibles.

Une bonne ligne directrice serait de vous assurer que chaque partie de l'application pourrait être modifiée avec un effet minimal sur les autres parties et que chaque partie a des tests unitaires et d'intégration de couverture complète automatisés.


1

L'architecture consiste à s'assurer que vous pouvez continuer à vous développer à long terme. Pour les applications plus importantes, cela implique de faire des compromis entre rendre les choses indépendantes afin que plusieurs personnes puissent travailler simultanément et éviter la duplication (DRY) afin que le projet puisse rester agile. Les projets PHP ont tendance à se concentrer sur le fait de rendre les choses indépendantes et ont une grande quantité de duplication.

Pour avoir une bonne idée de l'autre position extrême, jetez un œil à Seaside


1

Si vous ne savez pas comment structurer un grand projet, vous devez emprunter la conception / l'architecture des autres en utilisant l'un des nombreux bons cadres PHP. Je recommanderais CakePHP, CodeIgniter ou Symfony. Tous ces implémentent un modèle, vue, contrôleur, patten MVC qui fonctionne bien dans le développement Web, ils sont tous assez légers et faciles à apprendre.

Une fois que vous aurez appris à connaître l'un de ces cadres, vous serez peut-être en mesure de concevoir votre propre structure pour votre projet particulier, mais si vous débutez, je me tiendrais sur le travail des autres par rapport à la réinvention de la roue.


0

MVC est l'architecture la plus utilisée, qui s'est révélée résoudre la plupart des problèmes. Une bonne architecture aura les caractéristiques suivantes (et plus, ou bien sûr)

  1. Il peut être testé à l'unité
  2. Séparation des préoccupations
  3. Plusieurs personnes pourront y travailler sans aucune collision.
  4. Il peut être étendu sans trop de problèmes
  5. Il peut être évolutif. Lorsqu'il s'agit de grands projets, l'évolutivité sera une préoccupation majeure. Checkout Kohana framework, bien écrit et très évolutif

0

avant d'écrire un code de production, prenez 2 semaines (nuits :) et lisez ce livre. Cela changera longtemps d'avis sur l'architecture de programmation, les pratiques et le packiging.

Principes, modèles et pratiques agiles C # par Prentice Hall

Les exemples sont en C # mais ils sont faciles à lire, il ne s'agit pas d'écrire la syntaxe de code correcte, mais de penser en tant que programmeur.

Je vous promets de le sauvegarder sur votre emplacement le plus accessible sur votre PC et vous serez étonné que vous ayez programmé sans le savoir. Cela changera votre façon de penser.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.