Moduli dinamici: Pattern o AntiPattern? [chiuso]

In generale non è un anti-modello. Non è diverso da come funzionano i linguaggi di programmazione, i browser e i generatori di report.

Una particolare implementazione di questo metodo può essere o diventare un anti-modello? Sì, proprio come qualsiasi altro programma. Come sempre, il diavolo è nei dettagli. Inoltre, come altri hanno notato, la complessità è forse la più grande sfida quando si crea questo tipo di programma.

Ho scritto diversi programmi come questo, per lo più riportano generatori e sistemi di presentazione dei contenuti, e ho cercato di mantenerli il più semplici possibile. Provo ad usare un tipo di metodo "fast food" per fornire una personalizzazione di massa. L'idea è di limitare le scelte dell'utente a un determinato numero di elementi di base e il modo di metterli insieme consentendo all'utente di avere un controllo limitato su determinati elementi.

Laddove l'eccessiva complessità arriva, di solito è il risultato della "doratura" del programmatore e / o delle eccessive richieste dell'utente. In alcuni casi, è meglio utilizzare un prodotto orientato all'utente orientato all'alimentazione (come la suite SSRS, Access o Hyperion Reporting) piuttosto che provare a reinventare la ruota.

Non è sicuramente un anti-pattern: quando questo è fatto correttamente, ti permette di completare applicazioni molto complesse in brevissimo tempo. Ho lavorato per un'azienda che ha costruito tutti i suoi prodotti in quel modo e ha avuto molto successo in quello che ha fatto ^* .

L'unico problema con questo approccio è che è estremamente difficile avere ragione. Ad esempio, ci sono voluti un team di una cinquantina di programmatori altamente specializzati, per lo più del MIT e del Caltech, circa tre anni per costruire la piattaforma. Una volta costruita, tuttavia, la piattaforma è stata consegnata in modo bello: siamo stati in grado di mettere complesse applicazioni in produzione nel giro di pochi mesi.

Il più grande vantaggio dietro questo approccio è che consente agli analisti di business con poche conoscenze di programmazione di creare applicazioni ragionevolmente complesse. La programmazione di tali sistemi è spesso solo leggermente più complessa rispetto alla programmazione di Excel, pertanto le persone con conoscenza del dominio potrebbero essere addestrate a creare i moduli, la loro archiviazione di backup e le regole aziendali che controllano il flusso di dati.

Penso che ogni volta che ho provato a fare qualcosa di simile ho finito con lo scartare il sistema e ricominciare da capo. Per me stava creando un albero in un db e con un campo tipo. Quel campo tipo mappato a vari modelli. Voglio dire sì, roba di tipo db relazionale tecnicamente è come definire un albero personalizzato, ma interrogare un tavolo gigante finisce per causare problemi di prestazioni. Comunemente ci sono eccezioni a varie regole che finiscono per causare il tuo schema db non conforme agli acidi o semplicemente brutto. È molto più semplice definire chiaramente la propria architettura utilizzando nomi di modelli tangibili. Morale della trama: non generalizzare un problema.

Detto questo, c'è un altro paradigma che afferma che il tuo codice sono dati. In quel processo di pensiero si potrebbe dire che salvare le tue applicazioni in un DB ha senso ... Suppongo ...

Fare i giri non è facile, ma suppongo che non sia diverso da come i sistemi come wordpress o drupal fanno giri sui loro documenti.

Come @dasblinkenlight ha detto che sembra difficile. Direi che è eccessivamente complicato. A volte è necessario fornire un meccanismo per consentire agli amministratori di creare moduli. In questi casi è meglio non salvare l'intero codice HTML del modulo stesso. Quindi salva i dati del modulo compilato separatamente e lascia che gli amministratori li setacciano, a loro piacimento.

Considero la creazione dinamica di forme un anti-pattern per software su misura , ma per COTS o software di pacchetti quell'utente non può decidere sul comportamento o aspetto, potrebbe essere una buona scelta. Sebbene sia importante considerare la rigidità apportata dalle forme dinamiche.

Il motivo è che per una semplice richiesta di modifica di una forma potrebbe diventare un incubo.

Ha vantaggi e svantaggi.

I vantaggi:

• Le modifiche ai moduli diventano attive senza attendere l'implementazione o eventuali tempi di inattività.
• I non programmatori possono modificare i moduli utilizzando un'interfaccia utente più amichevole.

Svantaggi:

• È più facile rompere i moduli e / o renderli incompatibili con il codice back-end.
• Richiede strumenti personalizzati speciali da mantenere (sebbene questi strumenti siano l'intero punto).
• Potrebbe essere più difficile vedere il sistema nel suo complesso (dipende dai tuoi strumenti).
• È difficile creare un editor di moduli davvero flessibile.
• Un editor di moduli davvero flessibile diventa difficile da usare come editor di codice o più difficile.

Quindi vedo alcune nicchie in cui questo approccio dovrebbe andare bene:

• Quando gli utenti devono modificare i moduli, ma sono presenti vincoli significativi (quindi la flessibilità è limitata ed è più difficile rompere le cose);
• Durante la prototipazione rapida, esp. da utenti non tecnici;
• Quando le modifiche dinamiche rapide ai moduli sono molto importanti (non è facile inventare un caso per questo, ma potrebbe esistere).

Ovunque, prenderei un approccio diverso.