Approccio di sviluppo: interfaccia utente o modello di dominio in uscita?

Né

Nel corso degli anni ho sviluppato software mi sono trovato a praticare una prima metodologia perché c'è sempre una "via di mezzo" da prendere in considerazione. Metti un'interfaccia tra il codice dell'interfaccia utente e il codice aziendale e fai un accordo su ciò di cui l'interfaccia utente necessita al momento dal dominio.

Fammi fare una figura per rendere questo concetto cristallino:

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

In questo modo puoi lavorare in modo iterativo sull'interfaccia utente e sul modello di dominio separatamente se il terreno di mezzo rende più chiaro su quali dati l'interfaccia utente può ricevere.

Il motivo per cui vedo perché alcuni progetti diventano non mantenibili è perché l'interfaccia tra i dati e la presentazione è stata affrettata o inesistente (con il codice di gestione dei dati diretto è nell'interfaccia utente ). Ho visto così tanti progetti in cui il codice di database risiedeva nel codice del modulo che ho perso la fiducia nell'umanità. Solo i pochi progetti che ho visto hanno questa rigida via di mezzo che ripristina quella fede perduta.

Non importa da quale parte fine inizi prima ... ciò che conta è che tu abbia una chiara separazione delle preoccupazioni sul posto. Quel contratto nel mezzo definisce praticamente l'applicazione o il sistema a portata di mano. Pensaci prima prima di andare a bottom-up o top-down .

Dipende molto dall'applicazione a portata di mano.

Se stai costruendo un'applicazione client / server chiusa, l'approccio sarebbe sufficiente; come si sta andando a manipolare il back-end per soddisfare le esigenze dei front end ha bisogno inevitabilmente.

Se stai costruendo un'applicazione client / server aperta in cui un potenziale servizio web sarà esposto per essere utilizzato dai tuoi clienti, è fondamentale sapere che il servizio potrebbe essere utilizzato da un cliente per sviluppare un front-end.

Spesso in ritardo rispetto a una spinta di piccoli cicli iterativi in fase di sviluppo (Scrum, Kanban, ecc.) il front end e il back-end vengono eseguiti in parallelo. Si tratta di fornire quello che ti serve per quella determinata iterazione; ignorando il costruirlo nel caso in cui ne abbiamo bisogno approccio . In un approccio parallelo, entrambe le estremità restano molto più vicine durante lo sviluppo, il che può alleviare la necessità di un cambiamento continuo quando il front end e il back end si fondono. Questo è il mio approccio preferito quando possibile.

Hai menzionato ...

...WPF has some dynamic binding features that makes it possible; but there are limitations. Inevitably some code that belongs in the domain model ends up in the GUI classes...

Non sei sicuro di cosa intendi con alcuni ? WPF e SL sono entrambi noti per la loro funzionalità di rilegatura. È infinito Se si è costretti a posizionare il codice all'interno della vista in un'applicazione WPF basata su MVVM, è necessario risolvere il problema. Comportamenti associati sono un modo per implementare il comportamento senza legare gli eventi all'interno della vista, così come molti altri approcci per garantire che il tuo View rimanga pulito.

Il front end da una posizione di interazione dell'utente deve avere niente da fare con l'implementazione back-end. Il back-end termina con un solo front end: fornire dati tramite dati di elaborazione o altri mezzi. Questo si ricollega al tipo di applicazione in fase di sviluppo.

Assicurarsi che il codice sorgente sia gestibile è davvero una questione completamente diversa in sé e per sé. Ad un livello elevato si riferisce alle migliori pratiche di codifica e ai seguenti schemi, architetture e tecnologie provati.

Domain first. I need to make sure the system is correct before we put a UI on it.

Nient'altro può essere fatto funzionare - tranne in casi semplici.

Partire dall'interfaccia utente spesso porta a software fragile e buggato che può sembrare divertente, ma spesso presenta problemi gravi nel modello.

Non è scontato che l'interfaccia utente sia destinata a fallire - se il modello è abbastanza semplice, allora l'interfaccia utente può essere costruita prima con la certezza che il modello funzionerà alla perfezione alla fine.

In ogni caso in cui il modello non può essere facilmente immaginato, deve prima essere costruito.

Il caso peggiore è dove alcuni programmatori pensano di poter immaginare il modello. Potrebbero aver omesso dettagli importanti, casi speciali, eccezioni o considerazioni sulle prestazioni. Poiché la GUI è già stata costruita e molte considerazioni sono state omesse, il modello è terribile.

Cerchiamo di guidare il nostro software con test automatici. I test dell'interfaccia utente automatizzati sono molto dannosi. Gli script per controllare alcuni valori su una console sono più semplici.

Tenendo questo a mente, stiamo abbastanza attenti a mantenere la logica aziendale separata dall'interfaccia utente.

Ricordo che una volta anche uno sviluppatore principale mi ha urlato che l'architettura Document / View era considerata obsoleta quando ho suggerito che dovevamo interrompere l'associazione di tutto il nostro codice aziendale con l'interfaccia utente (e stavamo usando Win32 in C ++ al momento questa attività di programmazione drag & drop non era nemmeno il nostro problema). Ero semplicemente sbalordito.

IMNSHO, semplicemente non ci sono scuse per non avere almeno un livello di business vs. interfaccia utente. Se il tuo prodotto fa qualcosa di leggermente interessante, è assolutamente necessario che questa separazione abiliti il riutilizzo del codice.

Come sviluppatore C #, sicuramente non penso che tu sia incasellato a lavorare fuori casa. Preferisco fare prima il modello del dominio, in realtà.

Per WPF, l'unico lato negativo del modello che ho descritto, quindi, è che a volte è necessario mediare tra l'interfaccia utente e il modello di dominio. Tuttavia, mentre a volte questo significa più lavoro, significa anche codice più pulito.

Preferisco prima progettare l'interfaccia utente di base (anche se è solo su carta), con l'input del cliente. Il cliente potrebbe non sapere davvero cosa vogliono fino a quando non lo vedono. Non puoi sempre fidarti di ciò che ti dice il cliente. Potresti investire settimane scrivendo un solido modello di dominio solo per scoprire che non si adatta a ciò che il cliente capisce di volere dopo aver iniziato a vedere i prototipi dell'interfaccia utente.

Certamente, prima il dominio!

La bellezza di Smalltalk era che si poteva facilmente "guidare" un modello di dominio in molti modi, incluso fare "stamparlo" da uno spazio di lavoro o da un ispettore. Solo quando eri sicuro che il tuo dominio si stava comportando come desiderato hai osato concentrarti sulla costruzione della GUI perfetta.

Questo non vuol dire che Smalltalkers non abbia funzionato contemporaneamente sui due, ma quando la GUI non è riuscita a implementare la logica di business, in genere è stato risolto il modello di dominio, invece di inserire casi speciali nella GUI.