Controller e ri-factoring per mantenibilità / sensibilità

Question

Controller e ri-factoring per mantenibilità / sensibilità

#1 da (4 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)

7

Ho letto molti post simili a questo sul sito: tuttavia sto ancora chiedendo cosa è meglio nella mia situazione (anche le risposte sono contraddittorie da una domanda all'altra).

Ho un sito web (applicazione web) con un controller per sezione di logica di dominio (cioè ProductsController, NewsController, ContactsController, ecc.) e un controller admin molto brutto molto grande che contiene la logica per Aggiungi / Modifica / Visualizza / Cancella le funzioni per ogni sezione ... ora come puoi immaginare questo controller sta diventando molto fuori controllo (considerando che ogni funzione non è eccessivamente grande, poiché dozzine di funzioni in un controller non si adattano bene a me ...).

Da quello che ho letto il consenso generale è quello di limitare le funzioni admin nel controller delle sezioni; tuttavia alcuni suggeriscono anche di creare un nuovo controller per ogni sezione di amministrazione. quindi vorrei avere ProductsController e AdminProductsController - questo mi sembra un po 'eccessivo, ma non ne ho idea: qualsiasi suggerimento o lettura sarebbe apprezzato - o se c'è una "best practice del settore" che sarebbe bello sapere anche.

refactoring php mvc

posta rlemon 24.07.2012 - 15:17

fonte

4 risposte

Leggi altre domande sui tag refactoring php mvc

Attivazione di eventi personalizzati in callback AJAX Rails - per usare STI o no ... questa è la domanda

score 4 · Answer 1

Quando si lavora con pattern ispirati a MVC per il Web, si consiglia di avere una relazione 1: 1 tra Controller e Viste . Questo dovrebbe dividere il tuo codice in blocchi molto più gestibili.

Inoltre, come effetto collaterale, potresti incontrare situazioni in cui stai ripetendo lo stesso codice esatto con solo strutture differenti dal livello del modello. Ad esempio, elencando gli ultimi documenti e gli ultimi utenti. Il flusso di codice in entrambe le coppie di visualizzazione del controller è lo stesso, l'unica differenza è l'origine dei dati.

Per separare ulteriormente l'amministrazione da parti pubbliche, puoi mettere parti rilevanti in diversi spazi dei nomi, che poi vengono mappati a sottodirectory con lo stesso nome dal caricatore di classe.

score 1 · Answer 2

Dichiarazione di non responsabilità: la mia esperienza con MVC deriva esclusivamente da Joomla!

Penso che separare Admin / pubblico sia esattamente ciò che si vuole fare. Personalmente, non terrei i controller nello stesso file, ma conserverò tutti i componenti di amministrazione nella loro sottodirectory. Questo riduce la complessità visiva e la mantiene semplice.

score 1 · Answer 3

Ecco come faccio a deporre i miei controller. Ogni controller è responsabile per un gruppo specifico del mio sito.

Cartella dei controllori

application/controllers/
  admin/
    utilities.php
    accounts.php
    invoices.php
  profile/ - any user based controllers, same as above maybe?
  auth.php - all login, password resets etc.

Cartella viste

application/views
  utilities/
    partials/
      _form.php
    add.php
    edit.php
    index.php
    view.php
  accounts/
  invoices/

score 0 · Answer 4

Perché refactoring? In modo che sia più facile da mantenere in seguito.

Che cosa è più facile da mantenere?

Ogni amministratore importa nel controller "sezioni", inquinando i tuoi probabilmente già grandi controllori.
Ogni amministratore è importante in un nuovo controller per ogni sezione.

Come rispondi a questa domanda ti dice cosa dovresti fare.

E come suggerisce @SomeKittens, fa sembra che tu voglia separare la parte di amministrazione nella sua cartella.