I framework PHP modulari migliorano davvero le applicazioni?

3

Uno degli obiettivi dei framework modulari come Kohana o Alloy facilita l'aggiunta e la rimozione di componenti (ad es. "plug-in" o "moduli").

Tuttavia, in tutti i progetti più grandi che abbia mai lavorato, il sistema spesso dipende dai moduli su cui è basato. Dopotutto, è per questo che sono lì - per costruire con loro.

Quindi, mi chiedo se il concetto di creare distinte sezioni separate di un'applicazione web come moduli indipendenti sia anche una buona idea per cominciare? Ad esempio, potremmo costruire un utente generale, forum e modulo blog - ma ogni progetto è diverso e di solito comporta la creazione di molti livelli di astrazione per aggiungere nuove funzionalità o la modifica diretta dei file per personalizzarli. Non riesco a riutilizzare lo stesso modulo su più progetti.

In altre parole, non sono più solo un componente aggiuntivo plug-in-play al sito.

Ora non sto confondendo questo con una corretta progettazione della classe per garantire MVC e logica di libreria non accoppiate . Ma mi chiedo se "MMVC" sia stato uno sforzo superfluo per applicare anche concetti di design di classe adeguata alla progettazione delle applicazioni. Dopo tutto, molti sistemi di migrazione o librerie di database come Doctrine richiedono tutte le relazioni enunciate nei modelli dal primo giorno, collegando in tal modo le entità.

È una di quelle cose che suona come una buona idea quando il progetto inizia, ma alla fine si dimostra una caratteristica inutile? I moduli hanno il loro posto in sistemi come wordpress - ma non in framework in cui ovviamente stai costruendo qualcosa di personalizzato?

    
posta Xeoncross 15.09.2011 - 05:27
fonte

2 risposte

4

Lo scopo dei moduli e dei framework non è tanto quello di ottenere l'indipendenza delle funzioni quanto quella di raggiungere la riusabilità e la flessibilità. Nella maggior parte delle altre occupazioni, questo tipo di riutilizzo della funzione e della flessibilità è fondamentale per raggiungere il successo.

Pensa a quanto sarebbe difficile lavorare sulla tua auto se dovessi comprare un set di strumenti completamente nuovo per ogni auto, perché gli strumenti non erano intercambiabili. O peggio, devi costruire gli strumenti da zero, perché non c'era una fabbrica per crearli. Entrambi questi concetti (universalità di innesto e fabbriche di oggetti) sono presenti in moduli e strutture ben scritti.

...but each project is different and usually involves building many layers of abstractions to add new features - or editing the files directly to customize them. I can't re-use the same module on multiple projects.

Stai descrivendo un accoppiamento stretto, un tratto indesiderato del software che è destinato ad essere riutilizzato. Librerie, framework e moduli correttamente scritti ottengono un accoppiamento lento attraverso modelli software come Inversion of Control, message passing e metodi di comunicazione universalmente comprensibili come REST e XML. Questi non sono gli unici metodi con cui si può ottenere un accoppiamento libero.

Ovviamente, è impossibile scrivere un sistema completamente disaccoppiato; una parte del sistema deve sapere qualcosa sull'altra parte del sistema, o nulla viene realizzato. Ma un alto grado di disaccoppiamento può essere raggiunto comunque.

Scrivere software modulare richiede più lavoro e lungimiranza rispetto alla scrittura di sistemi strettamente accoppiati, ma lo sforzo può valerne la pena, specialmente quando si scrive un framework o una libreria che verrà utilizzato da molte persone.

    
risposta data 15.09.2011 - 07:30
fonte
2

L'onnipresente pattern MVC dei framework attuali è una forma di modularità forzata ... ma non è il tipo di modularità basato sulle funzionalità a cui la maggior parte della gente pensa quando pensa alla parola. Le applicazioni della vecchia scuola erano tradizionalmente molto più modulari, che rendevano più trasparenti e migliori riflessioni dell'esperienza utente.

La modularità basata su feature definisce gruppi di file di origine e / o strutture di codice in base alle funzionalità dell'applicazione, ad esempio:

  • un processo di accesso
  • una nuova procedura di registrazione dell'account
  • un forum di discussione
  • un catalogo di prodotti ricercabili
  • una nuova procedura di immissione degli ordini
  • ecc.

Quindi, per una procedura di accesso, potresti avere:

  • i file sorgente hanno nomi come "login.php" e / o "class.login.php" e / o "login_view.php", ecc.
  • funzioni di codice denominate cose come "RenderLoginForm ()" e / o "ProcessLoginForm ()", ecc.
  • classi di codice denominate cose come "LoginProcess", ecc.

Per essere veramente modulare, ogni modulo deve interagire con i controller delle applicazioni centrali, gli script di test automatici, ecc. Per fare ciò, potresti avere:

  • L'intero modulo racchiuso in una classe / funzione che può essere creata / chiamata da un programma di tipo di routing centrale
  • L'intero modulo contenuto in un file sorgente che può essere chiamato o incluso da un programma di tipo di routing centrale
  • Parametri di input e output che possono essere passati e restituiti dalle funzioni per indicare quali record sono interessati, cosa fa il modulo, cosa succede prima e dopo, ecc.

La modularità MVC separa nettamente lingue : SQL (nel modello), HTML / CSS / JS (nella vista) e PHP / Python / Ruby (nel controller). Ma MVC non sa nulla delle funzionalità. Un'applicazione veramente modulare offre un'architettura unica che può essere progettata solo da qualcuno che comprenda l'esperienza dell'utente e le esigenze aziendali. MVC, come la programmazione orientata agli oggetti, è semplicemente un modello di progettazione. È un cattivo sostituto di un'architettura applicativa vera, unica, pertinente e modulare.

MVC governa il paesaggio oggi e, a volte, è un modello meraviglioso. Ma un giorno la gente si sveglierà e si sbarazzerà delle sue catene abusate, arbitrarie e maldestre e riscoprirà architetture di applicazioni uniche e personalizzate.

    
risposta data 03.05.2014 - 23:51
fonte

Leggi altre domande sui tag