Construire une application PHP, confus sur les modèles de conception

Question

On m'a demandé de construire une application PHP qui insère des données dans une base de données, puis permet aux utilisateurs d'exécuter des rapports sur la base de données.

J'ai quelques années d'expérience de développement en PHP il y a quelques années, mais je suis coincé.

J'ai lu des articles sur MVC, cadres, etc ... et tout semble avoir changé :)

Quelle est la meilleure méthode à utiliser? J'ai l'impression d'avoir été bloqué dans le temps et de revenir à PHP et cela a complètement changé. Im questionnant tout ce que je savais :) Je ne sais même pas quelle structure de répertoire à utiliser pour poser l'application :)

J'espère que quelqu'un peut aider et offrir des conseils sur la façon de poser des applications sur ce que le principe de conception à utiliser, etc. .

S'il vous plaît aider im totalement perdu :)

Edit: Je préférerais ne pas avoir à apprendre un cadre, mais plutôt apprendre comment construire une application. :)

Answer 1

J'aime votre pensée.J'ai jeté un coup d'œil sur CodeIgniter, Cake et les autres frameworks et pendant qu'ils étaient bons j'ai décidé d'écrire le mien. J'ai appris une tonne. La première révision de mon framework n'était pas géniale mais j'ai deux sites qui fonctionnent sans problème. La deuxième édition n'est peut-être pas aussi mature que Cake etc, mais cela rend la création d'applications PHP aisée et la chose la plus importante pour moi est: Je sais ce que fait chaque ligne de code et il est super rapide de changer et déboguer.

Je pense que la première chose à faire est de penser à la façon dont vous allez briser l'application en couches, les candidats évidents sont:

• Front Controller: Une classe qui parse URL et décide ce qu'il faut faire avec leur. La plupart des frameworks actuels utilisent une règle de réécriture Apache pour transférer toutes les URL à une classe. Il s'agit donc d'un point d'entrée unique dans votre application.
• Couche d'abstraction de base de données: placez tout votre code qui lit/écrit dans une base de données à un endroit et faites en sorte que tout cela l'appelle. Aussi connu sous ORM.
• Modèles: Classes représentant une ou plusieurs tables de votre base de données.
• Contrôleurs: Classes qui mettent à jour/lisent les modèles, appliquent la logique et peuplent et affichent les vues. Vues: fichiers HTML qui importent des données de vos contrôleurs. J'utilise Smarty.

Donc, en prenant ces éléments, vous avez une structure de répertoire de base:

/models 
/controllers 
/includes 
/views 
/css 
/js 
index.php 

index.php est mon contrôleur avant. Et je mets des trucs ORM et d'autres classes auxiliaires pour faire du travail générique comme traiter des formulaires et des trucs dans le répertoire/includes. De toute évidence/css et/js héberge vos fichiers javascript et CSS statiques.

Le contrôleur frontal fonctionne en ce que vous avez des URL qui spécifient quel contrôleur créer - quelque chose comme: www.domain.com/product/1/hello-world. Où le produit est le nom d'une classe (j'appelle Controller de mon contrôleur) - ici, mon contrôleur frontal lisait la partie produit de l'URL et créait une instance de ProductController.

Les contrôleurs agissent sur le reste de l'URL qui leur est attribuée. Ainsi, ProductController obtient les paramètres de 1 et hello-world. 1 pourrait être l'indice d'un produit à charger et à afficher. salut-monde est juste un texte SEO à ignorer. Vous pouvez également spécifier des fonctions à appeler, donc www.domain.com/product/list - cette fois vous créez un ProductController et appelez la fonction de liste.

Il existe différentes façons de structurer une application MVC et les forums sont pleins d'arguments à ce sujet - ce que j'ai mis au-dessus de mes MVC ou non, mais le but principal est d'obtenir une bonne abstraction.

Je vous recommande de vérifier Smarty pour votre calque View. C'est une bibliothèque stable et fournit également la mise en cache HTML.

Answer 2

D'abord, choisissez un cadre. Ensuite, suivez la structure de répertoire dont il a besoin et les principes de conception qu'il utilise.

Answer 3

Les cadres sont simplement des moyens de s'assurer que vous adoptez les meilleures pratiques. Mais sur un petit projet, vous pouvez très facilement adopter de bonnes pratiques sans cadre. Tout ce dont vous avez besoin est une classe ou un ensemble de fonctions qui font toute l'interaction avec votre base de données. Ceux-ci vont générer les requêtes SQL en fonction des paramètres que vous leur transmettez. Ensuite, toute la logique de non-base de données doit être conservée séparément. En option, vous pouvez créer une classe ou un ensemble de fonctions pour gérer le code de visualisation (le bit qui génère réellement votre code HTML) et un autre pour gérer les bits entre, mais si vous arrivez à ce niveau de complexité MVC, vous être beaucoup plus rapide juste en apprenant un cadre.

Answer 4

Décomposition en étapes. Pensez à l'endroit où le code va être réutilisable.

Bien que je n'utilise pas un cadre standard, j'ai en quelque sorte construit un au cours des années. Ne vous méfiez pas des cadres, ils devraient être adoptés. Par exemple, mon cadre est assez simple et léger. Quand je commence un projet, je crée deux (parfois trois) répertoires:

cms/ 
inc/ 
tpl/ 

Ils sont assez explicites: cm abrite un système de gestion de contenu si nécessaire; inc contient des scripts PHP; et tpl contient des modèles et des actifs tels que des images, des feuilles de style et les fichiers JavaScript donnant:

cms/ 
inc/ 
tpl/ 
    css/ 
    img/ 
    js/ 

J'ai alors un fichier index.php qui prend une demande (c.-à-http://www.example.com/news/2010/11/05/lorem-ipsum) qui passe simplement la demande d'un script qui correspond à la premier segment (dans le cas ci-dessus news.php) et les segments d'URL restants sont utilisés comme paramètres. Donc dans mon exemple, chercher un article correspondant à une date (11 nov. 2010) et un nom de fichier (lorem-ipsum).

Ne pas trop travailler sur les choses. Planifiez-le d'abord et vous trouverez avec une tête claire que vous couperez une charge de sur-ingénierie.

Answer 5

Je sais vraiment ce que vous ressentez. Je suis un gars old school et je pense que je suis un peu résilient avec tous ces nouveaux trucs. Je ne peux pas utiliser un outil sans savoir exactement ce qui se passe. Désolé pour les frameworks évangélistes, et les développeurs mégaproductifs. Je pense que lorsque vous utilisez un framework, un CMS, ou des modèles de conception, vous manquez tout le plaisir. Les étudier vaut le coup. Juste en les utilisant n'est pas une si bonne chose à mon humble avis.

Eh bien, ces jours-ci, nous entendons beaucoup parler de la POO, des modèles de conception, etc.Apprendre ces choses peut valoir la peine. Mais comme le dit @Martin Bean, "ne pas sur-ingénierie". PHP fera de même, probablement encore mieux si vous le faites structuré (inclut, requiert, fonctions). Vous pouvez utiliser les «nouvelles» ressources progressivement, en apprenant leur base car elles ont du sens et vous vous sentez plus à l'aise.

Prenez le chemin sûr. Faites l'application comme vous le savez et essayez d'apprendre une ou deux nouvelles choses.

Answer 6

Comment Rasmus Lerdorf (co-créateur de PHP) le fait, "Le no-cadre PHP Framework MVC": http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html

Answer 7

Ne pas réinventer la roue .. utiliser Zend Framework http://framework.zend.com/, est un meilleur MVC structuré tu peux trouver. Commencez leur didacticiel de démarrage rapide.

Answer 8

Il s'agit plus d'une question de génie logiciel que strictement d'une question PHP. Il existe plusieurs modèles de développement de logiciels. PHP supporte certains mieux que d'autres, mais avec un peu de créativité, vous pouvez implémenter presque n'importe quel design.

Model View Controller

C'est l'architecture la plus commune que vous rencontrerez probablement sur des plates-formes web. L'idée est de découpler la logique d'application et les données des interfaces utilisateur. Cela donne au développeur la possibilité de fournir plusieurs interfaces (une interface mobile, une pour les services Web, une pour le navigateur, etc. - tout cela se passe dans la couche de vue) sans avoir à modifier la fonctionnalité principale de l'application. La couche modèle fournit les données et (jusqu'à un certain point) la logique métier. La couche contrôleur couple le modèle (données) et la vue (présentation). Le Zend Framework utilise MVC, et Django (Python) utilise une variante de MVC.

Model View Presenter

Comme le MVC, le modèle utilise un (stuff de données) et la vue, mais le contrôleur est remplacé par un composant de présentation. L'idée derrière le composant de présentation est très similaire au contrôleur, mais la différence est que le présentateur enlève une partie de la responsabilité de la vue dans MVC. La vue dans MVP est strictement pour le rendu. Le MVP est principalement destiné aux applications et composants d'interface utilisateur lourde. Windows Forms l'utilise.

Three Tier

Le système à trois niveaux utilise un niveau de présentation, un niveau de logique métier, et un niveau de données. Le niveau de présentation gère les demandes entrantes, les réponses sortantes et le contenu de rendu. Le niveau logique de l'entreprise fait le gros du travail. Il traite la demande et prend des décisions en fonction de ces demandes. Le niveau de données se compose des données réelles - si elles résident dans une base de données ou s'il s'agit d'un service Web à partir duquel vous tirez des données.

Presentation Abstraction Control

PAC est comme MVC, mais beaucoup plus granulaire, et se compose de ce qui est un peu comme de petites architectures MVC qui sont tous séparés les uns des autres. Celui-ci est probablement beaucoup plus de travail que vous cherchez à faire.