Come organizzi il tuo framework MVC mentre supporti moduli / plug-in? [chiuso]

La risposta a questa domanda è stata dettata dalla PSR- 0 Proposta che tutti i sistemi di grandi dimensioni stanno iniziando ad adattare o che hanno adottato ora.

La struttura è:

\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

Questo significa che non c'è niente che puoi fare per correggere nomi di file lunghi:

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

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

Questo significa anche che devi usare file muti di maiuscole e minuscole invece di tutte minuscole (se non fai librerie di terze parti non funzioneranno).

Prova:

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

I tuoi modelli sono il cuore della tua applicazione. Dovresti progettarli e codificarli come pacchetto autonomo. I controller sono solo client del tuo modello, che capita di tradurre l'attività dell'utente in azioni per il tuo modello. Una vista è solo un modo particolare di visualizzare i dati dal tuo modello. Se la tua applicazione cresce, potresti andare ancora oltre nel separare i client dal modello:

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

/model
    User
    BlogPost
    Comment
    ....

Ciò dovrebbe rendere evidente che puoi avere più client, che in un modo o nell'altro, interagiscono con un singolo modello.

;)

Ho trovato la migliore struttura per un framework MVC / HMVC combinato. Per il main è necessario utilizzare i controller / modelli / viste di base ... ma per i singoli componenti dei moduli del corso ...

Quindi nella mia struttura framework MVC / HMVC assomiglia a questo:

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

Anche se ho bisogno di aggiungere librerie di moduli, i18n o helper.

La convenzione di denominazione è semplice, per controller e modelli aggiungo suffisso _Controller e _Model. Per controller e modelli dai moduli aggiungo anche un prefisso con nome modulo, ad es. controller Profile in module User sarà nominato come User_Profile_Controller.

Quindi è molto facile e veloce trovare ciò di cui hai bisogno.

Problem: Long names (Forum_Model_Forum)

La denominazione sistematica delle classi aiuta ad evitare conflitti di denominazione tra i componenti. La lunga nomenclatura delle classi non imporrà gravi sanzioni in termini di prestazioni. Trovo che questo schema di denominazione sia piuttosto utile durante la codifica perché è facile vedere cosa viene da dove.

file system searches (which folder has the forum model?).

Questo dipende molto da come il sistema è stato implementato, ma la struttura del file system solitamente segue una convenzione che consente l'accesso immediato al componente corretto senza estese ricerche di file system.

Ecco un esempio, supponiamo che il componente del forum debba essere usato:

Info:

• Nome-componente: forum

• Nome controller: indice

  $ controller_path = BASEDIR. 'modulo /'. $ component_name. '/ controller /'. $ controller_name. '.Php';

È anche importante notare che ci sono letteralmente centinaia di query sul file system quando si avvia un tipico sito Web, quindi aggiungere alcune non danneggerà.

Ho lavorato con siti web che hanno iniziato con il primo "MVC standard", ma alla fine, sono diventato "MVC modulare".

Se stai facendo un sito Web di piccole dimensioni e non hai molta esperienza, potresti iniziare con "MVC standard". Se sai già che il sito web sarà molto complesso e grande, dovrai abituarti al "Modular MVC", sarà un po 'difficile all'inizio, ma alla fine ti abituerai esso.

In realtà sto lavorando su un framework e uso una combinazione di strutture di directory sia in moduli che in formato libero. La mia struttura predefinita per il codice del sito che utilizza il framework è:

/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)

Puoi anche avere una cartella modulo che non si riferisce a un controller e ce n'è una predefinita Core chiamata che viene utilizzata per memorizzare modelli di sito come l'intestazione e il piè di pagina. Questo per me dà il meglio di entrambi i mondi. Puoi facilmente sapere dove si trova il controller dato che c'è un solo controller per cartella, ma per classi come i modelli non è necessario cercare dove sono i file così come sono in una directory (che mantiene anche i nomi dei modelli più puliti) .

Il modo in cui carico i file è un po 'diverso in quanto permetto all'utente di configurare le diverse directory su dove possono essere le classi, quindi analizzo le directory inizialmente e memorizzo tutte le posizioni dei file di classe in un file json e poi lo uso per cercare tutte le altre richieste (anche se sto cercando dei modi per migliorarlo).

La soluzione di Mathias ha molto senso E l'uso della sua struttura di cartelle non impedisce di avere contenuti collegabili, ad esempio aggiungendo un indipendente / galleria / potrebbe apparire come questo

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

Ora abbiamo un "modello" condiviso e, se necessario, indipendenti