7
votes

Structure de dossiers d'un cadre PHP MVC ... Est-ce que je fais ce droit?

Je travaille actuellement sur mon propre PHP Framework, et j'ai besoin d'aide pour déterminer si je vais dans la bonne direction ou non ...

Le cadre est à la fois pour mon propre usage et d'une manière générale avance mes compétences en PHP plus loin. J'ai rencontré de nombreux problèmes en les surmonter, je l'ai beaucoup appris, et l'amour d'être en mesure de créer quelque chose à partir de rien, donc je préfère ne pas voir les réponses comme « Il suffit d'utiliser Zend »! ;) P>

J'ai lu un tas d'articles à la fois sur le débordement de pile et un tas d'autres sites, mais ne peut pas tout à fait obtenir la bonne réponse que je besoin, donc nous espérons que quelqu'un peut me donner quelques conseils utiles! P>

J'ai essayé quelques solutions différentes, mais je viens a fini par me confondre et je ne suis pas sûr dans quelle direction aller maintenant! Ne peut pas tout obtenir ma tête tout ... p>

Structure-cadre 'théorique' strong> p>

- .htaccess
- index.php
- private/
    - app/
        - bootstrap.php
        - modules/
            - default/
                - controllers/
                    - pages.php
                    - index.php
                - models/
                - views/
            - admin/
                - controllers/
                - models/
                - views/
    - config/
        - config.php
        - autoloader.php
    - lib/
        - Some_Library
            - Class1
                - class1.php
            - Class2
                - class2.php
- public/
    - css
    - images
    - scripts


1 commentaires

me rappelle la structure de répertoire symfony ;-)


3 Réponses :


1
votes

Je vous suggérerais d'utiliser un bootstrap.php qui gère tous les routiers afin que vous ne rencontriez jamais de problèmes tels que "J'aimerais pouvoir nier un dossier davantage dans mon module d'administration".

Je n'utiliserai pas non plus de modules et conserver les contrôleurs par défaut à l'intérieur du contrôleur / dir et des contrôleurs d'administrateur à l'intérieur du contrôleur / Admin Dir. idem pour les modèles et les vues.

BTW n'est pas vraiment intelligent de ne pas partager les modèles entre différentes parties de votre application, ils seront les mêmes dans 99% de tous les cas. C'est pourquoi MVC est si puissant. Parfois, vous pouvez même partager certaines des pièces de vue dans votre application entre le front et le backend.


1 commentaires

J'ai créé une classe de routeurs, qui acceptera une variable / une variable de reroute 'de quelque sorte, probablement sous la forme d'une chaîne. La variable sera quelque chose comme "admin", et si ce modèle est apparié dans l'URL, le routeur se configurera pour charger des contrôleurs à partir du dossier "Admin /". Je penserai à des manières plus efficaces / efficaces après avoir été triés. Les modules ont été mis au rebut, je vois pourquoi ils ne sont pas nécessaires =) et je vais maintenant partager des modèles et des points de vue, je peux voir comment cela fait plus Sense maintenant! Merci!



2
votes

Une solution pour l'acheminement d'administration est ce que CakePHP fait, Vous définissez d'abord une configuration pour la chaîne d'administration puis dans votre contrôleur, utilisez des actions avec une conversion de nommage spécifique xxx

, vous pouvez généraliser ceci à l'aide d'un système de routage Il suffit de regarder votre framework préféré

sur une autre note

  1. Le dossier des modules semble être unecesary
  2. Je suis d'accord avec AntPaw Vous devez ajouter une vue globale et un dossier modèle afin de les partager à travers les applications
  3. Je ne comprends pas pourquoi l'autoloader est à l'intérieur du répertoire de configuration et non dans le cadre du répertoire lib, vous pouvez également déplacer BOOSTRAP.PHP dans le répertoire de configuration

    espère que cela aide


6 commentaires

J'ai incorporé la solution CakePHP que vous avez montrée ci-dessus dans mon code actuel, avec quelques modifications. Au lieu d'avoir les actions pour les demandes par défaut et «admin» dans le même contrôleur, je l'ai fait, il y a donc un «index_controller» situé dans «contrôleurs / indextroller.php», ainsi que «admin_index_controller" dans "contrôleurs / admin /indexcontroller.php ". Je pense que cette solution fonctionnera, à moins que vous ne puissiez voir quelque chose de mal avec ça ..? En ce qui concerne # 2: voulez-vous dire que je devrais ajouter un dossier "vues" et "modèles" en dehors de l'application Dir? Ou simplement ajouter une "vue / commune" Dir et "modèles / communs"?


Question rapide .. Est-ce que cette classe MyController appelle d'autres contrôleurs ?? Si ma classe de routage (voir mon commentaire à la réponse d'AntPaw) peut configurer quel contrôleur / action à exécuter, serait-ce que la classe MyController serait nécessaire? Je ne vois pas tout à fait pourquoi vous initiez un contrôleur --Juste- pour initier d'autres contrôleurs .. Mais peut-être que je ne sais tout simplement pas assez sur MVC ou Cake ..


1. L'administrateur_index_controller semble être une solution raisonnable. Il bénéficie de la séparation d'administrateur une logique régulière dans deux classes différentes. 2. Je n'obtiens pas exactement ce que vous entendez par appel d'autres contrôleurs, son "contrôleur", le système de routage examine l'URL et la mappe à cette classe. La fonction admin_index n'est que le code derrière une action régulière, vient de router un peu différent. Au lieu de / mycontroller / admin_index / il créerait / admin / admin / mycontroller / index / en raison de la configuration


Je pense que je me suis confus où il a dit que "cela fera ma carte pour ..." penser que ces actions chargeront des contrôleurs de ces dossiers, mais je pense que cela signifie simplement que ces actions sont appelées par ces URL, et non qu'ils les appellent .. à droite? Je pense que je veux avoir des contrôleurs d'administration, etc. dans une classe et une structure complètement diff to the normales. Utilisateurs / ajoutez des itinéraires (via un routeur dans la bootstrap) sur les contrôleurs / usercontroller.php users_controller-> ajouter () et admin / utilisateurs / ajouter des itinéraires à des contrôleurs / admin / usercontroller.php (ou admin / contrôleurs / userscontrols.php ?? ) admin_users_controller-> ajouter (). Les pensées?


Désolé, ignorez le "S" sur le lien entre crochets!


Concernant l'autoloadeur - Si je le mets dans ma classe core_autoloader dans /private/lib/core/autoloader.php, et je veux l'initier à partir de mon fichier index.php avec 'spl_autoload_register (tableau (' core_autoloader ') ); ', Je devrais inclure manuellement le fichier de classe ... Quel type de défaite le but d'un autoloadeur, non?



2
votes

Je sais que cela a été posé il y a longtemps, mais j'étais exactement la même situation il y a quelques jours.

La solution proposée par l'Asker est essentiellement ce que je suis allé avec curieusement. Fondamentalement, j'ai emprunté un concept d'ASP.NET MVC2 appelé "Zones". Les zones sont des sections du site qui ont leurs propres contrôleurs et leurs propres contrôleurs (également des modèles, mais je ne sais pas pourquoi ... les modèles doivent généralement être universels). Donc, c'est très similaire à votre idée initiale.

Dans tous les cas suivant leur dossier + la structure de routage a tout à fait un sens pour mon application (zone de type administrateur, espace utilisateur et un autre niveau entre les deux) . Jetez un coup d'œil à cela et vous pourriez trouver un succès là-bas.

Mon routage prend simplement en compte les domaines. Les itinéraires sont codés durs, donc si j'ai besoin d'une autre zone, je viens d'ajuster mon fichier de routage. Oh aussi, mes automoducteurs sont définis pour regarder dans le dossier de la zone si une zone $ est spécifiée.

/ admin / t'aire / ajouter / est lu comme, zone: admin, contrôleur: admin, contrôleur: Équipe, Action: Ajouter

tandis que

/ équipe / / p>

Structure de dossier un peu comme ceci: xxx


1 commentaires

+1 J'aime l'idée que modèles devraient généralement être universels