Outre les concepts OO standard, quelles sont les autres stratégies permettant de produire du code PHP propre et de qualité, lorsqu'un framework n'est pas utilisé?
Réponses
Trop de publicités?Rappelez-vous: MVC, POO et les niveaux sont des concepts de design, pas de constructions de langage, ni de fichier de structuration.
Pour moi, cela signifie que lorsque vous n'utilisez pas un cadre, et quand il n'y a pas d'équipes différentes pour la programmation et la conception; il n'y a pas de valeur en utilisant un autre système de template sur le dessus de PHP (qui est un langage de template). Aussi, en séparant le code de mise en page n'est pas nécessairement de le faire sur des fichiers différents.
C'est de cette façon j'ai l'habitude de faire des one-off, rarement élargi, PHP, web apps:
- écrire un "services généraux" fichier, là, j'ai mis en forme/désinfection des fonctions, ainsi que de quelques DB fonctions d'accès:
- getquery(): étant donné un SQL, renvoie un objet de résultat
- getrecord(): étant donné un SQL, retourne un objet d'enregistrement (et ferme la requête)
- getdatum(): étant donné un SQL, renvoie un seul champ (et ferme la requête)
- mettre toutes les configurations (DB d'accès, certains préfixes d'URL, etc) sur un "config.php' fichier
- écrire un modèle de couche, soit un fichier, ou un pour chaque objet que vous stockez sur DB. Il sera de toutes les constantes SQL, présentent un plus grand niveau de l'API, basée sur vos objets conceptuels, pas sur DB records.
c'est votre "cadre", ensuite, vous écrivez la "présentation" d'une couche:
d'un fichier PHP pour chaque page, commence avec un peu de simple code pour récupérer les objets nécessaires, suivi par le HTML avec interspeced code PHP, juste à "remplir les trous". à de très rares exceptions, la plupart des complexes de code il devrait y avoir des boucles for. Je fais une règle de n'utiliser qu'un seul-liners, l'
?>
devrait être dans la même ligne que l'ouverture d'<?php
chaque formulaire d'inscription doit pointer vers un petit PHP sans aucun code HTML, que tout simplement obtenir les données POST, entre dans la DB, et la transmet à l'appel de la page.
et c'est tout. Si l'on travaille seul, il a tout de la séparation des intentions dont vous avez besoin, sans se noyer dans un grand nombre de fichiers pour une seule action de l'utilisateur. Chaque page vue par l'utilisateur est géré par un seul fichier PHP.
Il est même facile à maintenir, après quelques mois sans regarder le code, car il est facile de tester l'application, en prenant note des noms de fichier dans le champ d'adresse URL du navigateur. Ce guide vous directement sur le code.
(de nos jours, bien sûr, je suis en utilisant Django pour presque tout...)
Je dirais à peu près la même que pour tout autre langue:
- Ne pas optimiser prématurément
- Garder méthodes petite
- Pratiquer SEC
- Pratiquer piloté par les données de programmation
- L'utilisation judicieuse des raccourcis (par exemple, tertiaire de l'opérateur)
- Format votre code pour qu'il puisse être comprise par les autres
- N'utilisez pas aveuglément OO
- Toujours vérifier les codes de retour pour les erreurs
- Permettre au plus haut niveau d'avertissement et vous assurer que votre code ne produit pas d'avertissements
- Être très prudent quand il s'agit de taper des questions (cela vaut pour toutes faiblement typé langues). Le '===' opérateur est votre ami.
En fait cette question est tout à fait la langue agnostique, tel qu'il s'applique à la plupart des langues où vous choisissez de "rouler propre". Deux suggestions, je serait :
Tout d'abord, tout simplement parce que vous n'êtes pas à l'aide d'un cadre ne signifie pas que vous ne pouvez pas adopter les tendances de la ségrégation du code. Le modèle MVC est le minimum que vous devriez considérer lors de l'organisation des vous code source, il est beaucoup plus simple et plus facile à maintenir collection de code source, même si l'application n'est pas tout à fait suivre le processus de routage associés avec les cadres, ayant le code qui "fait" les choses séparée de ce qui "représente" les choses est très bénéfique.
Deuxièmement, juste parce que vous avez choisi de ne pas utiliser un plein cadre, ne signifie pas que vous avez besoin de réinventer la roue. Utiliser les pré-emballés, les bibliothèques de discernement en vue de résoudre des problèmes spécifiques. Deux bons exemples de journalisation (log4php) et un front-end de rendu/templating solution (Smarty).
Si vraiment vous ne suivez OO concepts, tels que la séparation des préoccupations, votre code sera très bon, mais voici quelques suggestions:
- Cadre ou pas, l'utilisation de MVC.
- Je ne peux pas souligner assez combien il est important de ne jamais mélanger votre logique avec votre code HTML. Dans un fichier HTML, PHP doit être utilisé uniquement comme un modèle de langue et rien de plus.
- Utiliser un DBAL.
- Séparer votre conception de votre contenu. Une méthode commune pour le faire, c'est à l'aide de CSS fortement et avoir de l'en-tête et pied de page des fichiers contenant l'essentiel de la mise en page du site.
- Avoir un seul fichier pour l'option constantes, comme DB informations d'identification, les informations d'identification FTP, etc.