Separazione di presentazione e logica

Personalmente preferisco il codice a strati liberamente accoppiati. Nel tuo caso, avrei poche interfacce con la mia implementazione. Tuttavia, vorrei anche offrire ai consumatori l'opportunità di giocare con determinate cose.

Quindi, vorrei iniziare con le interfacce che forniscono dati al mio grafico. Supponendo che usi dati provenienti da un database, potrei usare un livello database che funziona con IDbConnection e altre di tali interfacce. Ora, posso supportare qualsiasi cosa abbia un provider che utilizza queste interfacce.

Il prossimo è l'elaborazione. Una volta che i dati sono disponibili, abbiamo bisogno di un modo generico per farli passare. Quindi, pensa ad altre interfacce che ti aiutano a farlo. E il tuo modello (classe la cui istanza rappresenterebbe i dati) deve implementarlo. Ciò consente di aggiungere e rimuovere facilmente le regole aziendali.

Ora, l'aspetto. Per i controlli, preferisco utilizzare eventi pubblici con un gestore predefinito incorporato nel controllo stesso insieme alle proprietà. Per esempio. al clic su una barra nel grafico a barre, il colore dovrebbe diventare rosso. Ora a un consumatore piace il verde, quindi, dargli una proprietà per farlo. Vuole anche un suggerimento e altri dettagli sul passaggio del mouse. Quindi, dagli un evento da gestire.

Capisco che sia troppo generico e spero che sia almeno un po 'utile.

Sembra che tu stia operando sotto una strana idea di cosa significhi "separazione delle preoccupazioni". Se il tuo progetto richiede effettivamente di scrivere il doppio del codice, stai facendo qualcosa di molto, molto sbagliato.

Un'architettura multistrato funziona per applicazioni web line-of-business complesse perché le traduzioni tra database, business logic e DOM sono così spinose e soggette a migrazione. Per un focus più ristretto, come la progettazione di una singola classe PHP per tradurre una matrice di numeri e un oggetto blob di proprietà in un grazioso grafico, la separazione può e deve essere più stretta e compatta.

Probabilmente vorresti una separazione tra l'archiviazione interna dei dati del tuo controllo e l'interfaccia che utilizzi dall'esterno, ma solo perché vorresti testare e verificare su questo. (E non appena finisci la tua demo di "non aver mai bisogno di cambiare questo", ti verrà chiesto di creare una versione per cellulare o stampare o qualcosa del genere.)

Quindi la domanda: la separazione tra la presentazione dei dati e la logica vale la pena anche se richiede come 2x o 3 volte più codice per mantenere tutto coerente e sincronizzato? (sì, intendo 2x o 3x).

Consiglio vivamente di separare i livelli. Ci sono alcuni motivi:

• I controlli spesso iniziano in modo semplice e diventano più complessi nel tempo.
• I controlli possono essere riutilizzati in altre aree di un'applicazione o di altre applicazioni.
• Se i controlli devono interagire tra loro, avere gli eventi isolati semplifica enormemente il codice.

Separare la presentazione dalla logica è una linea guida, non una regola.

Anche se la maggior parte dei casi MVC è una buona idea, ci sono alcuni casi in cui non lo è. Pensa a "dipingere" o "photoshop" quanto senso avrebbe a separare la presentazione dalla "logica" quando l'intero punto della "logica" è manipolare ciò che viene presentato.

Mi sono imbattuto in questo nelle applicazioni di trading. Wo chiunque sia che presenti i dati di un trader usando qualsiasi cosa tranne i colori dei terminali di Rueters. Il posto migliore per impostare questi colori è nel livello di presentazione utilizzando le regole aziendali. Puoi farlo nella "logica aziendale", ma questo significa inviare una tonnellata di informazioni extra al livello di presentazione - sulla presentazione; in entrambi i casi stai infrangendo la "regola".