Passer d'un cadre à un sans cadre [fermé]

Je développe en PHP depuis environ 8 ans comme passe-temps. En 2009, j'ai repris codeigniter et depuis je n'ai pas réussi à faire développer un seul projet.

Je trouve que cela me ralentit en essayant de trouver comment le modifier pour qu'il fonctionne comme je le souhaite, alors que si je travaillais en PHP pur, je le saurais ou je pourrais trouver rapidement un extrait de code.

J'ai essayé CodeIgniter, Kohana et Symfony. J'adore la facilité d'utilisation (et j'ai également commencé à utiliser la doctrine comme ORM, ce qui a considérablement accéléré le travail de ma base de données), mais je trouve que les projets me prennent 3 à 4 fois plus de temps en PHP pur. Je m'ennuie et me frustre quand je ne trouve pas de solution à un problème que j'ai déjà résolu en PHP pur.

Quelqu'un est-il revenu de l'utilisation de cadres à une approche sans cadre. Existe-t-il quelque chose qui ressemble à un cadre de sécurité de base (empêcher XSS, filtrer les données publiées, fournir une fonction de nettoyage à utiliser avec les bases de données)? Je pense que quelque chose comme ça me profiterait beaucoup plus qu'un cadre à grande échelle. Je pense qu'apprendre à travailler avec des frameworks m'a beaucoup appris, mais je serais plus heureux de travailler avec mon propre code.

Les versions actuelles de PHP5 incluent une grande partie du cadre de sécurité que vous recherchez dans le cadre de la bibliothèque standard.

• Utilisation filter_input_array pour nettoyer de manière déclarative les éléments provenant de l'extérieur.
• Accédez à votre base de données via PDO avec SQL paramétré pour éviter les attaques par injection SQL.
• Utilisez les paramètres PHP suivants pour rendre votre site plus résistant à la fixation de session et au vol de cookies:
  • session.use_only_cookies (empêche votre jeton de session de fuir dans l'URL)
  • session.cookie_httponly ou l' httponlyattribut à session_set_cookie_params () (Protège contre les scripts lisant le cookie de session dans les navigateurs compatibles)
  • Plus de suggestions et d'exemples de code PHP disponibles sur Wikipedia .
  • Vous pouvez également utiliser l' httponlyattribut avec setcookie () .
• Rien de plus sophistiqué que la création de modèles de base et la configuration d'en-tête n'est requis pour les nouvelles fonctionnalités HTTP et HTML5:
  • HTTP Strict Transport Security (aide à se protéger contre les exploits WiFi.)
  • Options X-Frame (Restreindre l'intégration de vos pages. Bonne contre le phishing.)
  • Attribut HTML5 IFrame Sandbox (annonces / badges / vidéos de Sandbox tiers. Déjà dans WebKit. Probablement au moins partiellement implémenté dans Firefox 11.)
  • Politique de sécurité du contenu (nouveau cadre de sécurité de Firefox 4, complémentaire de l'attribut sandbox. Désormais également implémenté dans Chrome .)

Si vous acceptez le HTML comme entrée, je vous recommande de saisir HTML Purifier et de l'appeler via un FILTER_CALLBACK ligne dans votre configuration filter_input_array. Son approche de la sécurité des entrées basée sur la liste blanche constitue une excellente (et très puissante) première ligne de défense contre XSS.

Autant que je sache, PHP n'est pas livré avec un mécanisme de protection contre falsification de requêtes intersites , mais je suis sûr que Google peut vous aider. Les cheatsheets de sécurité OWASP incluent une section si vous souhaitez mettre en œuvre votre propre protection.

Par curiosité, j'ai décidé de commencer également à regarder des composants autonomes et voici ce que j'ai trouvé jusqu'à présent:

Création de modèles:

• Héritage de modèle PHP (PHP normal plus héritage de modèle)
• TWIG (Django / Jinja2 / Liquide syntaxe de style y compris autoescape et sandboxing. Compile vers PHP mis en cache pour plus de vitesse.)
• Dwoo (Un successeur PHP5-ish plus rapide et plus fonctionnel de Smarty . Inclut un système de compatibilité pour les modèles Smarty existants.)

Des choses que je n'ai toujours pas examinées correctement:

• Répartition de l' itinéraire (seulement trouvé RouteMap et Net_URL_Mapper jusqu'à présent. Merci, cweiske.)
• ORM (juste au cas où l'AOP nu n'est pas votre truc)

Je ne crois pas aux frameworks ... J'ai travaillé dans beaucoup d'entre eux.

Raisons de détester les frameworks MVC:

1) Code bloat, j'achète des classes premium qui m'aident dans le développement. Tels que les classes de formulaire ou les classes SQL.

2) Je pense que les frameworks MVC ne sont pas facilement portables, en particulier lors de l'utilisation de gestionnaires de dépendances.

3) Je pense que vous écrivez en fait plus de code avec un framework MVC alors si vous deviez utiliser un passe-partout avec une tonne de classes utiles qui gèrent l'authentification, etc.

4) La plupart des frameworks ne prennent en charge qu'une ou deux bases de données nativement.

Je suggérerais de trouver un cadre de formulaire avec authentification et éditeur de texte et un cadre SQL comme madoo + une classe de messagerie ...

90% de votre demande est toujours des classes de formulaires, sql et ajax - le reste peut être acquis en cas de besoin

Je suis minimaliste et je lutte avec l'idée d'avoir du code dans mon application qui ne fait rien ... juste au cas où j'en aurais besoin, cela ne fonctionne pas pour moi.

Avec autant d'expérience derrière vous, vous devez avoir votre propre ensemble de bibliothèques préférées, les choisir manuellement et créer votre propre cadre simple. Framework ou pas de framework (et lequel à cela) dépend du type de projet à portée de main, aucun gant ne convient à tous. Donc, je suggère fortement que si vous sentez que les cadres existants vous ralentissent, passez du temps et proposez un cadre qui fonctionne selon vos besoins.

Sur la base de votre déclaration selon laquelle vous avez utilisé PHP comme passe-temps, ainsi que de votre déclaration de profil «Arriver lentement», cela semble être un problème de courbe d'apprentissage. Vous ne semblez pas avoir la profondeur et l'étendue de l'expérience pour a) comprendre comment travailler dans la structure que le cadre impose et b) vous êtes donc incapable de bénéficier des gains d'efficacité que le cadre permet.

Je vous exhorte à vous y tenir. Revenez au début avec les didacticiels vidéo. Trouvez et lisez le code d'autres personnes jusqu'à ce que vous le compreniez. Construisez vos projets de bas en haut - démarrez simplement et ajoutez des fonctionnalités. Suivez les forums en essayant de répondre vous-même aux questions avant de lire les réponses.

Je programme professionnellement depuis près de 20 ans, sur une variété de plates-formes, et il m'a encore fallu un certain temps pour me familiariser avec CI. Mais maintenant que je le suis, je ne retournerais pas au PHP pur (pour mes propres projets) à moins d'avoir un site d'une taille suffisante pour exposer des problèmes de performances quantifiables (pensez à Twitter).

Zend Framework est vraiment super pour ça. Vous pouvez en utiliser autant ou aussi peu que vous le souhaitez. Tout est codé en php et open source afin que vous puissiez simplement le pirater et le personnaliser. Les différents composants ne dépendent pas les uns des autres autant que dans d'autres cadres.

Vous pouvez construire vous-même un framework simple en utilisant certains composants de Zend sans aucun problème.

Vérifiez -le!

Je sais exactement ce que tu ressens. J'ai commencé il y a 4 ~ 5 ans en PHP (je viens de Delphi, lol), et j'ai commencé en php pur. Ce que j'avais en arrière, c'était un "CMS Panel like" qui lisait simplement tous les champs des tables et créait le formulaire. Après un certain temps, j'ai atteint d'une manière ou d'une autre la connaissance de PHP Frameworks, j'ai essayé CakePHP pour la première fois et je n'ai pas aimé, après, je suis entré dans Yii qui, à mon avis, est assez intuitif et facile à utiliser (avec son générateur Gii, ça change beaucoup). J'ai essayé Symfony, ZF2, Laravel, Yii2-Beta et quelques frameworks pour RAD, mais je ne me sentais toujours pas assez vite comme avant les frameworks.

Il est arrivé que j'ai développé mon propre framework (ce n'est naturellement pas exactement que je me suis réveillé un jour et j'ai dit "je vais créer un nouveau framework", c'est arrivé avec le temps). Je sais que c'est une mauvaise mauvaise pratique et un mouvement de "réinvention de roue" MAIS, je développe maintenant mes projets beaucoup plus rapidement (plus que PHP uniquement).

Comme son code est un MESS total, j'ai commencé il y a environ un mois à reformuler mon framework, maintenant il utilise composer, suit les règles communes qui existent entre les frameworks php, est MVC.

Pourquoi je reformule? Parce que si quelqu'un a besoin de réparer un de mes projets, ce ne sera pas une autre chose du monde.

Alors je vous comprends.

Mon conseil est de préparer vos outils (appelez cela un framework, une application prédéfinie ou quel que soit le nom des gens), et utilisez-les comme vous vous sentez mieux, tout en respectant certaines règles courantes (comme MVC, des éléments "faciles à moduler" qui vous pouvez remplacer en cas de rupture.

Pour la sécurité de base, j'utilise une méthode de filtrage personnalisée qui englobe mes superglobales . Sa syntaxe nécessite un certain temps pour s'y habituer, mais elle est plus simple que l'API PHP filter_var () et ne vous laisse pas glisser la désinfection:

 $_GET->text("inputvar") or $_POST->name["field"]

Il permettait également l'échappement en ligne de $ _REQUEST-> sql (). Mais pour le travail sur la base de données, continuez à utiliser SQL paramétré ou votre DAL / ORM de choix.

J'ai fait une étude d'une journée sur ToroPHP et je l'ai trouvé assez sympa. C'est un cadre minimaliste destiné aux applications RESTful. Cela permet de garder le code côté serveur modulaire, sans avoir à gérer le gonflement de tout framework.

Je ne sais pas ce qui vous dérange mais codeigniter est un excellent framework.Il a une belle documentation et comme beaucoup de gens utilisent codeigniter vous trouverez toute l'aide dans sa documentation, ou forum ou sur stackoverflow.J'ai travaillé sur de nombreux frameworks ( Codeigniter, CakePHP, Zend, Spring 3.0, Ruby on Rails), mais je dois dire que codeigniter a la meilleure documentation.Il y a beaucoup de choses dans codeigiter qui sont automatiquement gérées et vous n'avez pas à vous soucier de la sécurité. Travailler sur le noyau PHP, c'est comme réinventer la roue. Eh bien, la chose la plus importante est que passer d'un noyau à un framework nécessitera beaucoup d'efforts une fois que vous y serez habitué, vous commencerez à l'aimer.Aussi Ruby on rails est aussi un excellent framework une fois que vous connaissez ses tenants et aboutissants, vous pouvez avoir une double vitesse.