Comment organisez-vous votre framework MVC tout en supportant les modules / plugins? [fermé]

17

Dans l'état actuel des choses, cette question ne convient pas à notre format de questions / réponses. Nous nous attendons à ce que les réponses soient étayées par des faits, des références ou une expertise, mais cette question suscitera probablement un débat, des arguments, un sondage ou une discussion approfondie. Si vous pensez que cette question peut être améliorée et éventuellement rouverte, visitez le centre d'aide pour obtenir des conseils.

Fermé il y a 6 ans .

Il y a deux structures de base de code principales que j'ai vues en ce qui concerne les frameworks MVC. Le problème est qu'ils semblent tous les deux avoir un bogue organisationnel qui les accompagne.

MVC standard

/controller
/model
/view

Problème: Pas de séparation des composants associés (forum, blog, utilisateur, etc.)

MVC modulaire

/blog
    /controller
    /model
    /view
/user
    /controller
    /model
    /view
/forum
    /controller
    /model
    /view

Choisir le système basé sur des modules vous pose un problème.

Noms longs (Forum_Model_Forum = forum / model / forum.php) (comme Zend)
Le système de fichiers effectue une recherche en utilisant is_file()pour trouver quel dossier a le modèle de forum? (Comme Kohana)

Y a-t-il d'autres structures MVC qui fonctionnent bien lorsque vous essayez de séparer différents modules? Y a-t-il des avantages de ces structures qui me manquent?

— Xeoncross
source

1

Je voudrais également ajouter que je veux une structure compatible PSR-0 afin que je puisse également utiliser des bibliothèques comme Zend et Doctrine si nécessaire.

— Xeoncross

9

Essayer:

/blog 
    /controller
    /view
/user
   /controller
    /view 
/forum
    /controller
    /view
/model
    User
    BlogPost
    Comment
    ....

Vos modèles sont au cœur de votre application. Vous devez les concevoir et les coder en tant que package autonome. Les contrôleurs ne sont que des clients de votre modèle, ce qui se traduit par la traduction de l'activité de l'utilisateur en actions pour votre modèle. Une vue n'est qu'une façon particulière d'afficher les données de votre modèle. Si votre application se développe, vous pouvez aller encore plus loin en séparant les clients du modèle:

WebClient
    /blog 
        /controller
        /view
    /user
       /controller
        /view 
    /forum
        /controller
        /view
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment
    ....

Cela devrait rendre évident que vous pouvez avoir plusieurs clients, qui interagissent tous d'une manière ou d'une autre avec un seul modèle.

— Mathias Verraes
source

+1 parce que je suis totalement d'accord avec votre explication des composants MVC et comment ils devraient fonctionner. Cependant, l'intérêt d'un module est que vous pouvez importer des modules créés par d'autres utilisateurs, de sorte que le fait d'avoir les modèles en dehors du chemin du module le rend moins "glisser-déposer". Cependant, votre méthode est très logique pour les applications qui n'utilisent pas de plugins ou de modules externes.

— Xeoncross

@Xeoncross c'est vrai, je n'ai pas vraiment pris en compte la réutilisabilité ici. Si c'est une exigence, vous pouvez en effet aller plus loin et avoir par exemple un module `` Utilisateur '' qui regroupe le modèle Utilisateur avec son contrôleur, et un module Blog qui regroupe le modèle BlogPost et Commentaire avec ses contrôleurs. Comme toujours: cela dépend du contexte :-)

— Mathias Verraes

2

;)

J'ai trouvé la meilleure structure pour un framework MVC / HMVC combiné. Pour la principale, vous devez utiliser des contrôleurs / modèles / vues de base ... mais pour les composants individuels des modules de cours ...

Donc dans ma structure de framework MVC / HMVC ressemble à ceci:

/application
  controllers/
  models/
  views/
  modules/
    blog/
      controllers/
      models/
      views/ 
    user/
      controllers/
      models/
      views/
    forum/
      controllers/
      models/
      views/

Aussi, si j'ai besoin, j'ajoute des bibliothèques de modules, i18n ou des assistants.

La convention de dénomination est facile, pour les contrôleurs et les modèles, j'ajoute le suffixe _Controller et _Model. Pour les contrôleurs et les modèles des modules, j'ajoute également un préfixe avec le nom du module, par exemple. Profil du contrôleur dans le module L'utilisateur sera nommé User_Profile_Controller.

Il est donc très facile et rapide de trouver ce dont vous avez besoin.

— Shogun
source

1

Problème: noms longs (Forum_Model_Forum)

La dénomination systématique des classes permet d'éviter les conflits de dénomination entre les composants. Le long nom des classes n'est pas susceptible d'imposer de graves pénalités de performance. Je trouve ce schéma de dénomination plutôt utile lors du codage car il est facile de voir ce qui vient d'où.

recherches dans le système de fichiers (quel dossier a le modèle de forum?).

Cela dépend beaucoup de la façon dont le système a été implémenté, mais la structure du système de fichiers suit généralement une convention qui permet un accès immédiat au composant correct sans recherches approfondies du système de fichiers.

Voici un exemple, supposons que le composant forum soit utilisé:

Info:

Nom du composant: forum
Nom du contrôleur: index

$ controller_path = BASEDIR. 'module /'. $ nom_composant. '/manette/' . $ nom_contrôleur. '.php';

Il est également important de noter qu'il y a littéralement des centaines de requêtes sur le système de fichiers lors du démarrage d'un site Web typique, donc l'ajout de certaines ne va pas nuire.

— Lea Hayes
source

Vraiment, les back-ends ne sont pas comme des applications côté client qui doivent démarrer rapidement, elles peuvent prendre le temps nécessaire pour configurer correctement le temps d'exécution. Bon point.

— Patrick Hughes

0

J'ai travaillé avec des sites Web qui ont commencé avec le premier "MVC standard", mais qui sont finalement devenus le "MVC modulaire".

Si vous faites un petit site Web et que vous n'avez pas beaucoup d'expérience, vous voudrez peut-être commencer par le "MVC standard". Si vous savez déjà que le site Web va être très complexe et grand, alors, vous devrez vous habituer au "Modular MVC", ce sera un peu difficile au début, mais, finalement, vous vous habituerez à il.

— umlcat
source

0

Je travaille moi-même sur un framework et j'utilise une combinaison de structure de répertoires basée sur des modules et de forme libre. Ma structure par défaut pour le code de site utilisant le framework est:

/Configuration (stored a bunch ini files for security related information like passwords)
/Functions (stores file(s) with standard procedural functions)
/Libraries (general use classes)
/Models (all models go here)
/Modules (each module refers to one controller
/Modules/Site (controller class store in this folder if there is a controller)
/Modules/Site/Views (views for the controller)

Vous pouvez également avoir un dossier de module qui ne se rapporte pas à un contrôleur et il y en a un par défaut appelé Core qui est utilisé pour stocker des modèles à l'échelle du site comme l'en-tête et le pied de page. Cela me donne le meilleur des deux mondes. Vous pouvez facilement savoir où se trouve le contrôleur, car il y a un seul contrôleur par dossier, mais pour les classes comme les modèles, vous n'avez pas besoin de rechercher où se trouvent les fichiers car ils se trouvent dans un répertoire (qui conserve également les noms des modèles plus propres) .

La façon dont je charge les fichiers est un peu différente car j'autorise l'utilisateur à configurer les différents répertoires sur où les classes pourraient se trouver. toutes les autres demandes (même si je cherche des moyens d'améliorer cela).

— ryanzec
source

0

La réponse à cette question a été dictée par la proposition PSR-0 que tous les grands systèmes commencent à adapter ou ont adoptée maintenant.

La structure est:

\Doctrine\Common\IsolatedClassLoader => /Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /Symfony/Core/Request.php
\Zend\Acl => /Zend/Acl.php
\Zend\Mail\Message => /Zend/Mail/Message.php

Cela signifie que vous ne pouvez rien faire pour corriger les noms de fichiers longs:

$controller = new \Blog\Controller\Archive => /Blog/Controller/Archive.php

/Blog
    /Controller
        Archive.php
    /Model
    /View
/User
    /Controller
    /Model
    /View
/Forum
    /Controller
    /Model
    /View

Cela signifie également que vous devez utiliser des fichiers stupides à casse mixte au lieu de tous les minuscules (si vous ne le faites pas, les bibliothèques tierces ne fonctionneront pas).

— Xeoncross
source

0

La solution Mathiases est très logique Et l'utilisation de sa structure de dossiers n'empêche pas d'avoir du contenu enfichable, par exemple, l'ajout d'un indépendant / galerie / pourrait ressembler à ceci

WebClient
    /blog 
        /controller
        /view
    /user (uses /model/User/)
       /controller
        /view 
    /forum
        /controller
        /view
    /gallery
        /controller
        /view
        /model
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment

Nous avons maintenant un "modèle" partagé et indépendant si nécessaire

— Timo Huovinen
source