alternativa a MVC che è liberamente accoppiata?

Question

Lavoro in un negozio web come programmatore PHP. La maggior parte delle volte usiamo buone pratiche di codifica ma non abbiamo molta struttura per il sito nel suo complesso.

Ora sono entrato nella mia fase di annoiarsi con alcune delle nostre pratiche e voglio espandermi e semplificare e generare alcune cose in un modo utile non solo per me, ma per gli sviluppatori di web programmatori ibridi in ufficio.

Un dipendente ci ha lasciato con un sito MVC scritto in PHP, e ho dovuto mantenerlo un po ', e ho capito come funziona, ma ho le mie lamentele, la mia lamentela principale è che è strettamente accoppiato con ogni pezzo dipendente su un altro. Vedo il vantaggio della separazione delle preoccupazioni, ma questo potrebbe confondere chiunque, tranne me, sta guardando il codice.

Ad esempio, se devo aggiungere una nuova pagina al sito, devo aggiungere una vista, quindi aggiungere un modello, quindi aggiornare il controller. Il metodo ad hoc per creare una nuova pagina è molto più semplice di questo e non richiede un programmatore.

Il mio giudizio era che questo era un metodo molto migliore per costruire, piuttosto che mantenere, un sito web.

Tuttavia, sarebbe bello avere alcuni schemi di progettazione in cui riutilizzare codice in modo efficace senza dipendere da più punti del sito.

Quindi la mia domanda è: esiste un modello di progettazione per la creazione e la gestione di siti Web che è molto più strettamente accoppiato? Non sto cercando piccole variazioni su MVC, ho bisogno di qualcosa di molto diverso da guardare, forse un qualche tipo di approccio plugin.

EDIT:

Grazie per le risposte finora! Un modo diverso di metterlo è che voglio che il codice sia fatto meglio nel mio ufficio. Faccio A) Spingere per MVC o B) trovare/costruire un'alternativa non confondente con i semi-programmatori. Utilizziamo già classi per cose come connettività DB e aiuto di Form. Il punto di questa domanda era di esplorare B.

Answer 1

C'è sempre un compromesso tra il confondimento del codice perché è altamente decostruzionista e il codice è confuso perché tutto ciò che è necessario fare X è distribuito casualmente attorno a un singolo file.

Il problema con quest'ultimo è che esattamente quello che è un modo "intuitivo" di dividere le cose in moduli monolitici differisce tra le persone. Il codice altamente scomposto e fattorizzato è quasi sempre più difficile da avvolgere, ma una volta fatto, la manutenzione diventa sia facile da fare. Non sono d'accordo sul fatto che sarebbe fuorviante per chiunque altro che l'autore lo guardi. I pattern di grande portata come MVC vengono utilizzati perché diventa più facile individuarli e lavorare su progetti strutturati attorno a loro nel tempo.

Un altro vantaggio dell'utilizzo di MVC è che in genere non si rende l'applicazione più difficile da mantenere per qualcuno che viene dopo di te se non si attacca al layering. Questo perché ora hai un luogo predeterminato in cui posizionare qualsiasi aspetto dell'implementazione di una nuova funzionalità.

Per quanto riguarda l'accoppiamento stretto, non è possibile implementare realmente una funzione senza che vi sia alcuna connessione tra gli strati. L'accoppiamento lento non significa che gli strati siano completamente ignoranti l'un l'altro - significa che uno strato non deve sapere come sono implementati gli altri livelli. Es .: il livello del controller non si preoccupa se si sta utilizzando un database SQL o semplicemente si scrivono file binari per mantenere i dati nel livello di accesso ai dati, solo che esiste un livello di accesso ai dati che può acquisire e memorizzare gli oggetti del modello per esso.Inoltre non si preoccupa di utilizzare PHP o Smarty non elaborati sul livello di visualizzazione, ma solo di rendere disponibile alcuni oggetti con nomi predefiniti. Per tutto il tempo il livello di vista non ha nemmeno bisogno di sapere che c'è un livello di controller - solo che viene chiamato con i dati da visualizzare pronti sotto i nomi sopra indicati forniti da/qualcosa /.

Answer 2

Devo dire che in realtà non vedo il tuo problema con MVC, dal momento che i tuoi modelli già utilizzano comunque. Penso che sia il modello che si evolve in modo naturale quando si tenta di aggiungere una struttura a un'applicazione.

Quando le persone iniziano a sviluppare un'applicazione PHP, il codice di solito è un grosso casino. La logica di presentazione è mescolata con la logica aziendale che è mescolata con la logica del database. Il prossimo passo che le persone prendono di solito è di iniziare a utilizzare una sorta di approccio basato sui modelli. Non importa se questo riguarda un linguaggio di template specializzato come smarty o semplicemente separare il markup della presentazione in un file separato.

Dopo questo, molti di noi scoprono che è una buona idea utilizzare funzioni o classi dedicate per la logica di accesso al database. Questo in realtà non deve essere più avanzato di creare funzioni specializzate per ogni query eseguita comunemente e collocare tutte quelle funzioni in un file di inclusione comune.

Mi sembra tutto molto naturale, e non credo che sia molto controverso. Ma, a questo punto, stai già utilizzando un approccio MVC. Tutto ciò che va oltre questo è solo più o meno sofisticato tentativo di eliminare la necessità di riscrivere il codice comunemente usato.

Capisco che questo potrebbe non essere quello che volevi sentire, ma penso che dovresti rivalutare MVC. C'è un numero infinito di implementazioni e, se è davvero il caso che nessuno di loro si adatta alle tue esigenze, puoi sempre scrivere la tua implementazione personale e più basilare.

Guardalo in questo modo: poiché stai già utilizzando un linguaggio modello, in genere devi creare prima un normale file PHP e quindi un file templare ogni volta che crei una nuova pagina. MVC non deve essere più avanzato di questo, e in molti casi non lo è. Potrebbe anche darsi che tutto ciò che devi veramente fare sia studiare gli approcci più sofisticati per gestire l'accesso ai dati e aggiungerlo al tuo sistema attuale.

Answer 3

Come modelli di framework, trovo che il pattern MVC sia uno dei metodi più "liberamente accoppiati" per creare un'applicazione.

Pensa alle relazioni come interfacce o contratti tra le parti dell'applicazione. Il modello promette di rendere questi dati disponibili per View e Controller. A nessuno importa esattamente come fa il al Modello. Può leggere e scrivere da un tipico DBMS, come MySQL, da file flat, da fonti di dati esterne come ActiveResource, purché soddisfi la sua conclusione.

Il controllore promette di rendere disponibili determinati dati per la vista e si affida al modello per soddisfare le sue promesse. Alla vista non importa come fa il controller.

La vista presuppone che i modelli e i controllori manterranno le loro promesse e potranno quindi essere sviluppati nel vuoto. Il modello e il controllore non si preoccupano se la vista sta generando XML, XHTML, JSON, YAML, testo in chiaro, ecc. Stanno trattenendo la fine dei contratti.

E, naturalmente, la vista e il controller devono essere d'accordo sul fatto che certe cose esistono. Una vista senza alcuna attività del controller corrispondente potrebbe funzionare correttamente, ma non potrebbe mai essere utilizzata.Anche se il controller non fare nulla, come potrebbe essere il caso in pagine statiche:

<?php 
class StaticController extends ApplicationController 
{ 

    /** 
    * Displays our "about" page. 
    */ 
    public function about() 
    { 
     $this->title = 'About Our Organization'; 
    } 
} 

poi la vista associata può solo contenere testo statico. (Sì, ho implementato cose come questa prima. È bello consegnare una vista statica a qualcun altro e dire "Basta scrivere su questo.")

Se si osservano le relazioni tra M, V e C come contratti o interfacce, MVC appare improvvisamente molto "liberamente accoppiato". Diffidare dell'esca dei file PHP autonomi. Quando inizi a includere e a richiedere una mezza dozzina di file .inc o a mixare la tua logica applicativa con il tuo display (di solito HTML) potresti aver accoppiato le singole pagine in modo più lento, ma nel processo hai fatto un casino di aspetti importanti.

<?php 
/** 
* Display a user's profile 
*/ 
require_once 'db.php'; 

$id = $db->real_escape_string($_GET['id']); 
$user_res = $db->query("SELECT name,age FROM users WHERE id = $id;"); 
$user = $user_res->fetch_assoc(); 

include 'header.php'; 
?> 
<h1><?php echo $user['name']; ?>'s Profile</h1> 

<p><?php echo $user['name']; ?> is <?php echo $user['age']; ?> years old!</p> 
<?php 
include 'footer.php'; 
?> 

Sì, "profile.php" e "index.php" sono completamente indipendenti, ma a quale costo?

Modifica: In risposta alla modifica: Spingere per MVC. Dici di avere "semi-programmatori" e non sono sicuro di quale metà (hai persone front-end che sono brave in HTML e CSS ma non in scrittori server-side con qualche esperienza di programmazione?) Ma con un Quadro MVC, puoi consegnare solo le visualizzazioni e dire "lavora su questa parte".

Answer 4

Il fatto che sia necessario creare un nuovo modello e un'azione controller quando è necessaria una nuova pagina non credo significhi che i livelli M, V e C siano strettamente accoppiati. Questa è solo la separazione delle preoccupazioni e contribuisce a un sistema disaccoppiato.

Detto questo, è abbastanza possibile rovinare completamente l'intento di MVC (e ho lavorato su un'app come questa) e farlo rendere i componenti strettamente accoppiati. Ad esempio, un sito potrebbe mettere il 'motore di rendering' direttamente nel livello Controller. Ciò ovviamente aggiungerebbe più accoppiamento. Invece un buon MVC sarà progettato in modo che il controllore sia solo a conoscenza del nome della vista da usare e quindi passerà quel nome al motore di rendering separato.

Un altro esempio di progettazione errata in un MVC è quando le viste contengono URL codificati. Questo è il lavoro del motore di routing. La vista dovrebbe solo essere a conoscenza dell'azione che deve essere chiamata e del parametro di cui l'azione ha bisogno. Il motore di routing fornirà quindi l'URL corretto.

Answer 5

Zend framework è molto liberamente accoppiato ed è molto buono. Check it out:

http://framework.zend.com

Questo articolo potrebbe essere utile anche:

http://blog.fedecarg.com/2009/02/22/zend-framework-the-cost-of-flexibility-is-complexity/

Answer 6

Si può provare codeigniter. È molto facile da imparare e non adotta rigorosamente MVC pur fornendo al tuo codice una buona struttura.

Answer 7

Code Igniter e Kohana (un discendente CI) sono OK, ma anche in modo approssimativo MVC. Mi piace il simple php framework. Non ti intralcia e fornisce le cose importanti, senza forzare una struttura o convenzioni complicate su di te.

Answer 8

Ah ... buoni vecchi argomenti MVC.

Devo gestire un'applicazione PHP con molte sfaccettature, le cui parti sono scritte in stile "MVC", ma non tutte. Peggio ancora, diverse parti hanno diversi modi di fare MVC, che sono tutti fatti in casa. E alcune pagine lo fanno da sole.

Il problema principale non è l'esistenza di una diversità nel codice framework, ma i codificatori hanno chiaramente fatto non a capire come astrarre le API. IMO, questo è il problema più grande con i framework MVC. Quasi tutto il codice con cui lavoro utilizza i "modelli" come luoghi in cui inserire le funzioni. È un incubo da mantenere.

per rendere questo mantenibile, IME avete bisogno di un paio di cose:

• Uno strato di accesso ai dati distinto e ben definito, il confine API di cui si occupa il recupero e la conservazione di storage persistente e molto poco altro .

  Non mi piace usare il termine "modello" per quello perché è controverso. Qualsiasi chiamata a quel livello non dovrebbe preoccuparsi di come i dati vengono archiviati, non dovrebbe nemmeno preoccuparsi di cose come gli handle del database: questo è all il lavoro del livello di accesso ai dati.

• Un dispatcher che è molto leggero e non fa alcuna magia al di fuori del solo dispacciamento.

Ora si può mettere tutto il resto in un posto che accetta le richieste e dei parametri, probabilmente normalizzati ed errori controllati dal dispatcher, preleva i dati (in genere come oggetti) di cui ha bisogno, rende i cambiamenti di cui ha bisogno per farlo, salva i dati di cui ha bisogno, le mani che i dati devono mostrare alla vista. Duecento righe di codice che arrancano attraverso l'attività funzionano per questo passo. Non è necessario estrarre i bit in funzioni in un altro file chiamato da nessun'altra parte. Puoi persino mettere la vista alla fine di questo file! L'idealismo è bello a cui aspirare ma il pragmatismo ha bisogno di un controllo perché è mantenibile.

(Va bene, Rant over ...) la mancanza di far rispettare un quadro

PHP significa che i migliori quadri fanno ciò che fa PHP: rimangono fuori strada. Alcuni dei codici più gestibili su cui ho lavorato avevano una singola istruzione require() nella parte superiore, eseguivano tutti la manipolazione dei dati con gli oggetti dati (nessun SQL in vista), quindi emettevano HTML circondato da funzioni del modello, con il controllo del modulo eseguito da una funzione costante API.