Approccio allo sviluppo: interfaccia utente in entrata o dominio modello in uscita?

Anche se non ho mai distribuito nulla con Smalltalk, il mio breve periodo di gioco ha sicuramente lasciato il segno. L'unico modo per descrivere l'esperienza è MVC come doveva essere. In sostanza, tutto il lavoro pesante per la tua applicazione viene eseguito negli oggetti business (o nel modello di dominio se sei così incline). I controlli standard sono in qualche modo associati agli oggetti business. Ad esempio, una casella di testo è mappata sul campo di un oggetto (il campo stesso è un oggetto, quindi è facile da fare). Un pulsante verrebbe associato a un metodo. Tutto questo è fatto con un'API molto semplice e naturale. Non dobbiamo pensare a oggetti vincolanti, ecc. Funziona e basta.

Eppure, in molte lingue e API più recenti sei costretto a pensare dall'esterno. Prima con C ++ e MFC, e ora con C # e WPF, Microsoft ha ottenuto che il suo mondo di sviluppatori è collegato ai costruttori di GUI dove costruisci la tua applicazione implementando i gestori di eventi . Lo sviluppo di Java Swing non è così diverso, solo tu stai scrivendo il codice per creare un'istanza dei controlli sul modulo. Per alcuni progetti, potrebbe non esserci nemmeno un modello di dominio, ma solo i gestori di eventi. Sono stato dentro e intorno a questo modello per la maggior parte della mia carriera.

Ogni modo ti costringe a pensare diversamente. Con l'approccio Smalltalk, il tuo dominio è intelligente mentre la tua GUI è stupida. Con l'approccio predefinito di VisualStudio, la tua GUI è intelligente mentre il tuo modello di dominio (se esiste) è piuttosto anemico.

Molti sviluppatori con cui lavoro vedono il valore nell'approccio Smalltalk e provano a inserirsi in quell'approccio nell'ambiente VisualStudio. WPF ha alcune caratteristiche di rilegatura dinamica che lo rendono possibile; ma ci sono delle limitazioni. Inevitabilmente parte del codice che appartiene al modello di dominio finisce nelle classi GUI.

Quindi, in che modo progetti / sviluppi il tuo codice? Perché?

• Prima la GUI. L'interazione dell'utente è fondamentale.
• Prima il dominio. Devo assicurarmi che il sistema sia corretto prima di inserire un'interfaccia utente.

Ci sono pro e contro per entrambi gli approcci. Il modello di dominio si adatta lì con cattedrali di cristallo e torta nel cielo. La GUI si inserisce in modo rapido e sporco (a volte davvero sporco).

E per un ulteriore bonus: come assicurarti che il codice sia mantenibile?

Né

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

Vorrei fare una figura per chiarire questo concetto:

  +------+
  |  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 è possibile lavorare in modo iterativo sull'interfaccia utente e sul modello di dominio separatamente se la via di mezzo rende chiaramente chiari i dati che 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 diretta dei dati è nell'interfaccia utente). Ho visto così tanti progetti in cui il codice del database risiedeva nel codice del modulo che ho perso la fiducia nell'umanità. Solo i pochi progetti che ho visto che hanno questa rigida via di mezzo ripristinano quella perdita di fiducia.

Non importa da quale fine inizi prima ... ciò che conta è che hai una chiara separazione delle preoccupazioni in atto. Quel contratto nel mezzo definisce praticamente l'applicazione o il sistema a portata di mano. Pensa a quello prima di andare dal basso verso l' alto o dall'alto verso il basso .

Prima il dominio. Devo assicurarmi che il sistema sia corretto prima di inserire un'interfaccia utente.

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

A partire dall'interfaccia utente spesso si ottiene un software fragile e difettoso che può sembrare divertente, ma spesso presenta seri problemi nel modello.

Non è un dato di fatto che prima 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 alla fine funzionerà bene.

In ogni caso in cui il modello non può essere facilmente immaginato, deve essere creato per primo.

Il caso peggiore è quando 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.

Questo dipende davvero dall'applicazione a portata di mano.

Se stai costruendo un'applicazione client / server chiusa, sarebbe sufficiente uno dei due approcci; poiché hai intenzione di manipolare il back-end per adattarlo alle esigenze del front-end, inevitabilmente.

Se stai creando un'applicazione client / server aperta in cui un potenziale servizio web sarà esposto per l'utilizzo da parte dei tuoi clienti, è fondamentale sapere come quel servizio può essere utilizzato da un cliente per sviluppare un front-end è fondamentale.

Spesso in ritardo per quanto riguarda una spinta di piccoli cicli iterativi in ​​sviluppo (Scrum, Kanban, ecc ...), il front-end e il back-end vengono eseguiti in parallelo. Si tratta di fornire ciò di cui hai bisogno per quella data iterazione; ignorando la compilazione nel caso in cui abbiamo bisogno che si avvicini . In un approccio parallelo entrambe le estremità rimangono molto più vicine durante lo sviluppo, il che può alleviare la necessità di un cambiamento continuo quando si fondono il front-end e il back-end. Questo è il mio approccio preferito quando possibile.

Hai nominato...

... WPF ha alcune caratteristiche di rilegatura dinamica che lo rendono possibile; ma ci sono delle limitazioni. Inevitabilmente parte del codice che appartiene al modello di dominio finisce nelle classi GUI ...

Non sai cosa intendi con qualcuno ? WPF e SL sono entrambi noti per la loro funzionalità di associazione. È infinito Se sei costretto a inserire il codice all'interno della tua vista in un'applicazione WPF basata su MVVM, allora qualcosa deve essere risolto. I comportamenti collegati sono un modo per implementare il comportamento senza legarsi agli eventi all'interno della vista, così come molti altri approcci per garantire che la vista rimanga pulita.

Il front-end da una posizione di interazione dell'utente non dovrebbe avere nulla a che fare con l'implementazione del back-end. Il back-end unico lavoro a un front-end è quello di fornire dati tramite l'elaborazione di dati o altri mezzi. Ciò si ricollega al tipo di applicazione in fase di sviluppo.

Assicurarsi che il codice sorgente sia mantenibile è davvero una domanda completamente diversa in sé e per sé. Ad alto livello si riferisce alle migliori pratiche di codifica insieme ai seguenti modelli, architetture e tecnologie comprovate.

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

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

Con questo in mente, stiamo abbastanza attenti a mantenere la logica di business separata dall'interfaccia utente.

Ricordo che una volta persino uno sviluppatore principale mi ha urlato che l'architettura Document / View era considerata obsoleta quando ho suggerito che dovevamo smettere di associare tutto il nostro codice aziendale con l'interfaccia utente (e all'epoca utilizzavamo win32 in C ++, quindi questa programmazione drag & drop cosa non era nemmeno il nostro problema). Ero semplicemente sbalordito.

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

Come sviluppatore di C #, sicuramente non penso che ti piaccia lavorare fuori. Preferisco fare prima il modello di dominio, in realtà.

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

Certamente, prima il dominio!

Il vantaggio di Smalltalk è che puoi "guidare" facilmente un modello di dominio in molti modi, incluso "stamparlo" da un'area di lavoro o da un ispettore. Solo quando eri sicuro che il tuo dominio funzionasse come desiderato, osi concentrarti sulla creazione della GUI perfetta.

Questo non vuol dire che Smalltalker non ha funzionato contemporaneamente sui due, ma quando la tua GUI non è riuscita a implementare la logica di business, in genere hai risolto prima il modello di dominio, piuttosto che inserire casi speciali nella tua GUI.