Come organizzi il tuo framework MVC supportando moduli / plugin? [chiuso]

17

Ci sono due principali strutture di codebase che ho visto quando si tratta di framework MVC. Il problema è che entrambi sembrano avere un bug organizzativo che li accompagna.

MVC standard

/controller
/model
/view

Problema: nessuna separazione dei componenti correlati (forum, blog, utente, ecc.)

MVC modulare

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

Scegliere il sistema basato su modulo ti lascia con un problema.

Nomi lunghi (Forum_Model_Forum = forum / model / forum.php) (Come Zend)
Ricerche del file system usando is_file()per trovare quale cartella ha il modello del forum? (Come la Kohana)

Esistono altre strutture MVC che funzionano bene quando si tenta di separare moduli diversi? Ci sono benefici di queste strutture che mi mancano?

— Xeoncross
fonte

1

Vorrei anche aggiungere che desidero una struttura conforme a PSR-0 in modo da poter utilizzare anche librerie come Zend e Doctrine, se necessario.

— Xeoncross,

9

Provare:

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

I tuoi modelli sono il cuore della tua applicazione. È necessario 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 ovvio che è possibile avere più client, che in un modo o nell'altro interagiscono con un singolo modello.

— Mathias Verraes
fonte

+1 perché sono totalmente d'accordo con la tua spiegazione dei componenti MVC e come dovrebbero funzionare. Tuttavia, il punto di un modulo è che puoi importare moduli creati da altri utenti, quindi avere i modelli al di fuori del percorso del modulo lo rende meno "drag-and-drop". Tuttavia, il tuo metodo ha molto senso per le applicazioni che non fanno uso di plugin o moduli esterni.

— Xeoncross,

@Xeoncross è vero, non ho davvero preso in considerazione la riusabilità qui. Se questo è un requisito, potresti davvero fare un passo ulteriore e avere ad esempio un modulo "Utente" che raggruppa il modello Utente con il suo controller e un modulo Blog che raggruppa il modello BlogPost e Comment con i suoi controller. Come sempre: dipende dal contesto :-)

— Mathias Verraes,

2

;)

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

Quindi nella mia struttura del 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 moduli librerie, i18n o helper.

La convenzione di denominazione è semplice, per controller e modelli aggiungo il suffisso _Controller e _Model. Per i controller e i modelli dei moduli aggiungo anche un prefisso con il nome del modulo, ad es. Profilo del controller nel modulo L'utente verrà nominato come User_Profile_Controller.

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

— Shogun
fonte

1

Problema: nomi lunghi (Forum_Model_Forum)

La denominazione sistematica delle classi aiuta a evitare conflitti di denominazione tra i componenti. La lunga denominazione delle classi non è suscettibile di imporre gravi penalità di prestazione. Trovo questo schema di denominazione piuttosto utile quando si codifica perché è facile vedere da dove viene.

ricerche nel file system (quale cartella ha il modello del forum?).

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

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

Informazioni:

Nome componente: forum
Nome controller: indice

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

Inoltre è importante notare che ci sono letteralmente centinaia di query sul file system all'avvio di un tipico sito Web, quindi l'aggiunta di alcuni non farà male.

— Lea Hayes
fonte

In verità, i back-end non sono come le app lato client che devono avviarsi rapidamente, ma possono impiegare il tempo necessario per configurare correttamente il tempo di esecuzione. Buon punto.

— Patrick Hughes,

0

Ho lavorato con siti Web che sono iniziati con il primo "Standard MVC", ma alla fine sono diventato "Modular MVC".

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

— umlcat
fonte

0

Attualmente sto lavorando su un framework e utilizzo una combinazione di strutture di directory basate su moduli e 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 del modulo che non si riferisce a un controller e ce n'è una per impostazione predefinita chiamata Core che viene utilizzata per archiviare modelli a livello 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 poiché esiste un controller per cartella, ma per classi come i modelli non è necessario cercare dove si trovano i file in quanto sono in una directory (che mantiene anche più puliti i nomi dei modelli) .

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

— ryanzec
fonte

0

La risposta a questo è stata dettata dalla proposta PSR-0 che tutti i sistemi di grandi dimensioni stanno iniziando ad adattare, o 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

Ciò significa che non è possibile fare nulla per correggere i 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 in maiuscolo anziché maiuscole (se non le librerie di terze parti non funzioneranno).

— Xeoncross
fonte

0

La soluzione di Mathiases ha molto senso E l'uso della sua struttura di cartelle non impedisce di avere contenuti collegabili, ad esempio l'aggiunta di una / gallery indipendente / potrebbe apparire così

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 quelli indipendenti, se necessario

— Timo Huovinen
fonte