MVC framework di gestione dei contenuti con un pannello di amministrazione

Question

MVC framework di gestione dei contenuti con un pannello di amministrazione

#1 da (0 voti)

3

Ultimamente ho sviluppato il mio sistema di gestione dei contenuti MVC utilizzando PHP e, almeno nella mia mente, sono un po 'bloccato con il design del sistema. Credo che ciò si applicherebbe anche alla costruzione di un sistema di gestione dei contenuti con un framework MVC esistente.

Sarà un po 'difficile da spiegare, quindi scusa in anticipo per il lungo dilemma.

Una piccola introduzione al sistema:

Attualmente i miei percorsi sembrano un po 'come questo (memorizzati come JSON):

{
    "/admin/:controller/:action/:params":"",
    "/admin/:controller/:params":"AdminController",
    "/admin":"AdminController",
    "/:page?/:subpage?":"IndexController"
}

I percorsi sono le chiavi, i controller predefiniti sono i valori. Se non esiste un controller predefinito, il router passa alla regola successiva. Ho fatto questo per separare il front-end del sito dal pannello di amministrazione.

I controller sono tutti in una directory per il momento, sebbene questo sia destinato a cambiare. Restituiscono o un modello che è stato compilato con i dati dei rispettivi modelli o semplicemente modifica la richiesta con cui sono stati istanziati.

Il problema:

Il mio problema è decidere come implementare controller separati che riguardano lo stesso modello per il front-end e il back-end in modo modulare.

Ad esempio, ho una pagina nel pannello di amministrazione che consente a un amministratore di inserire alcune informazioni private che sono destinate solo ad essere accessibili sul front-end con un nome utente e una password. Immagina che questo sia gestito da un InfoController nel back-end, per modificare le informazioni private, abbinate alla route /admin/info .

Che cosa succede se volevo creare un percorso per il front-end, per accedere alle informazioni private, con lo stesso nome del pannello di amministrazione ( /info )?

Il problema ha più senso nel contesto delle soluzioni che ho considerato, credo.

Soluzioni che ho considerato:

Il mio primo pensiero è stato quello di aggiungere tutti i controller relativi all'amministratore con Admin - quindi AdminInfoController e InfoController - ma io sono interessato a possedere un sistema modulare in cui tutti i percorsi, i controller e le viste (e CSS / JavaScript se necessario) relativi al modello Info sarebbero nella propria struttura di directory (qualcosa come /modules/info ).
Con il desiderio di modularità in mente, ho pensato di abbinare le rotte un po 'come /:module/:controller/:action , ma questo implicherebbe quindi che il pannello di amministrazione sia esso stesso un modulo, che avrebbe bisogno di accedere a tutti i moduli che il front-end può usare . Avrebbe senso?
Il design che ho pensato di più è quello di avere l'amministratore e il front-end come due concetti fondamentali distinti del framework. Condivideranno moduli che contengono controller e viste per entrambi.

In definitiva, sto cercando suggerimenti sull'approccio migliore qui, su eventuali alternative, e se sto pensando troppo a questo.

Sembra un po 'come se mi fossi impazzito con il perseguimento del mio design di sistema ideale che si mantiene con il pattern MVC (è anche la cosa giusta per un sistema come questo?). Grazie per la lettura, spero che abbia senso.

design-patterns php mvc content-management

posta Hexus 03.07.2014 - 22:59

fonte

1 risposta

Leggi altre domande sui tag design-patterns php mvc content-management

Dovremmo assumere un nuovo sviluppatore ora, o aspettare fino a quando il codice non sarà refactored per renderlo adatto per un ambiente di squadra? Azione separata da asserzione nei test unitari

score 0 · Accepted Answer

Ho risolto questo problema quando ho iniziato a utilizzare i provider di servizi con un contenitore di dipendenze per l'implementazione di un sistema di moduli.

Trattando i moduli come fornitori di servizi per l'applicazione è ciò che ha funzionato meglio, sia che stiano fornendo nuovi servizi o che forniscano dati a servizi esistenti, come i percorsi.

Il pannello di amministrazione è diventato esso stesso un modulo che fornisce semplicemente percorsi e servizi relativi all'amministratore nel contenitore. Qualsiasi altro modulo può fare la stessa cosa.

Percorsi predefiniti nella configurazione appaiono in questo modo nel formato JSON:

{
    "/:controller/:action/:params": {
        "namespace": "Darya\Core\Controllers"
    },
    "/:controller/:params": {
        "namespace": "Darya\Core\Controllers"
    },
    "/:page?/:subpage?": "Darya\Core\Controllers\IndexController"
}

I percorsi dei moduli possono avere un aspetto simile quando sono definiti in una classe di moduli (un fornitore di servizi):

// Route path to namespace prefixes:
// "/admin/info" would become "Darya\Module\Admin\Controllers\InfoController"
$router->add(array(
    '/admin/:controller/:action/:params'  => 'Darya\Module\Admin\Controllers',
    '/admin/:controller/:params'          => 'Darya\Module\Admin\Controllers',
    '/:controller/:action/:params'        => 'Darya\Module\Controllers'
    '/:controller/:params'                => 'Darya\Module\Controllers'
));

In questo modo tutti gli URL dell'applicazione sono belli ed estensibili. Il prossimo problema è decidere le priorità del percorso, ma diventa fuori tema.

L'iniezione di dipendenza è tua amica. :)